Select and implement a template engine (or The issue to discuss everything Framework refactoring)

[mbabker]

Implement this feature based off the framework branch. What would be the most helpful to me is to bring in the code and implement it into the template (copy it from /platformApp/templates/joomla/index.php).

[Chris-Jones-Gill]

As you know, I would prefer to use AngularJS ( http://angularjs.org/ ) without a template engine (it is one less thing to learn).

Just use the extended HTML and keep the code as simple as possible.

AngularJS is also designed to be testable, unlike its peers, so unit testing can be included with the project: http://docs.angularjs.org/guide/dev_guide.e2e-testing

To keep the protostar/joomla look and feel there is an angular bootstrap project: http://angular-ui.github.io/bootstrap/

There is also a nice UI project (that complements the angular bootstrap project) which can implement codemirror and tinymce into the front-end. Plus some other nice features, and a useful route matching function : http://angular-ui.github.io/

Comments/questions are welcome (I may not have all the answers though)

[b2z]

I am not familiar with all this template engines (using PHP's ^_^), so just a reference for almost the same question for the CMS: Mustache, Handlebarjs and Dust (PHP 5.4+) are there at the moment.

[Skullbock]

Just as a reference: Backbone.js http://backbonejs.org/ is also available and widely used

Daniele Rosario

On Thu, Apr 18, 2013 at 3:16 PM, Dmitry Rekun notifications@github.comwrote:

Just a referencehttps://groups.google.com/forum/?fromgroups=&hl=en#!topic/joomla-dev-cms/6AdCfMR9DBAfor almost the same question for the CMS: Mustache https://github.com/bobthecow/mustache.php and Handlebarjshttp://handlebarsjs.com/are there.

— Reply to this email directly or view it on GitHubhttps://github.com/joomla/jissues/issues/86#issuecomment-16575622 .

[Chris-Jones-Gill]

Backbone is (imo) more of a library than a framework, marionette.js [http://marionettejs.com/] is (probably) the best mvc framework based on backbone. It is also on github https://github.com/marionettejs/backbone.marionette

Like backbone, it has dependencies that make it into a framework...

MarionetteJS currently works with the following libraries:

jQuery v1.8.x or v1.9.x
Underscore v1.4.4
Backbone v1.0 is preferred. v0.9.9 and v0.9.10 should work still
Backbone.Wreqr
Backbone.BabySitter

This extends the learning curve, as you not only need to know marionette and backbone, but also underscore (which is useful to know anyway), and the other libraries. Plus any template engine you want to bolt onto the front of it (e.g. handlebars)

Also, testing backbone/marionette is not as integrated into the design as testing is with AngularJS (although you can apparently do it using the node Marionette client https://npmjs.org/package/marionette-client )

Like any framework, there are pro's and cons to using any of them, be it AngularJS, Marionette.js, knockout, CANjs, ember.js, or any of the others. TodoMVC is a great site to play with all the frameworks and see which one(s) you like. See http://todomvc.com/

So many choices, so many good solutions, however I still favour the (relative) simplicity of AngularJS and its inherent testability over the other framework - but I am sure there are plenty of others who would disagree and provide excellent reasons for using their preferred framework and/or templateing engine.

Chris.

[mbabker]

I definitely prefer simple over complex (but not to the point we sacrifice functionality obviously). The testing aspect is also important. There isn't a unit test suite for the app right now; that needs to change, so that should play into this as well.

[b2z]

For me the question now is - do we need a template engine or do we need a complex framework like AngularJS? JS Frameworks are new to me and I would prefer something more simple (like Mustache). Template engines more understandable to me as PHP dev. But, that's only my 2c. May be it is time to learn something new? :)

[mbabker]

We need something to do the rendering legwork that we've been spoiled with JDocument to do in the CMS. How much we want it to do determines how complex it needs to be. I forget where, but someone pointed out one of the many systems can handle routing; would we want the routing to be handled there or have that tied into the application using the Framework's Router package. How many JavaScript frameworks do we want to be dealing with also? Obviously, we should keep things as light as possible, and between the existing Bootstrap styling and the suggestion to use the blueimp file upload plugin (jQuery based), I think we're better off trying to use something compatible with jQuery.

[realityking]

I'm not sure a JavaScript solution like AngularJS or BackboneJS is the right fit for our community. We're still a very much PHP centered community and a solution like Smarty or Twig seems more appropriate.

I personally prefer Smarty's Syntax but Twig is probably overall the better solution. The most important improvement over the plain PHP templates we currently use in the CMS is to me that variables are autoescaped (in Twig by default, Smarty can be configured to do it) and have to be explicitly unescaped. This makes security reviews oh so much easier.

[AmyStephen]

How about a different approach entirely? Essentially, the route is going to hand off instructions to a rendering process. How about we start with an Interface (set of interfaces) that define the process? Then, fit a few of them in. That could be worthwhile.

Also, JDoc is the cat's meow baby. It's just missing some features (recursiveness) and it needs to be abstracted out from the CMS (like Cache, render output not Modules or Components). But, there is a lot of good value in there. Joomla's template market is the envy of other projects and they have already crossed over in support of other CMS'es. I would really hate to cut them off.

An interface based solution with adapters, etc., would set the Joomla Framework apart -- in a very good way.

[mbabker]

If JDocument were abstracted out just right, it would be a great add to the Framework. It's indeed very useful and handles what it does well, but getting it to do more hasn't been as easy. Maybe someone could look at doing that?

[realityking]

JDocument is great for templates but it does nothing for layouts. (They are just plain PHP files)

The reason why JDocument is not part of the Framework right now, is that it's very tightly centered around the Component/Module architecture. I think this has worked great for the CMS - but it's not a good approach for a generic framework.

[AmyStephen]

Any support for an Interface-first approach to this question?

[phproberto]

My vote goes for Twig. Everytime I see the Joomla! positions & think in the extendable Twig templates & the block system (aka a JLayouts improved).....

• Extendable templates.
• Reusable blocks (aka bye bye JLaoyouts).
• Simple sintax (almost as easy to learn as Smarty).
• Fully unit tested.
• JS independent.
• Easy to debug.

Also now that the framework is starting to use Symfony components.... :P

[mbabker]

I support the interface-first approach if it doesn't make a big impact to getting this task knocked out. I think if we can create some code reusable in the Framework (or distributed on its own *GASP*), then we're helping everyone out in the long run. But, we should have something figured out sooner than later because once we can get the application level code and the high-level MVC code and "component" code converted and implement a routing system, it's going to be hard to do too much else without an efficient way to display our pages.

[AmyStephen]

Maybe I should ask - what do you mean by selecting a template engine for the framework? There is a lot that goes into considering how to support the rendering process -- and it does start with the question of what does a route of example.com/person/mbabker mean in terms of rendering? -- which leads to what are the blocks or extensions of this system.

That's the kind of thinking that needs to occur, how that comes about can differ, but there's a bit more to it than picking a engine, is my point.

Rather than propose an approach, maybe I should ask you, what's your first goal to use it and how do you see the concept of extensions factoring in?

[mbabker]

Extensions really won't be a factor, everything will be built into the core application code. #87 is the sounding board for what we know now as components and how that should be structured (and whether we really need a two-app system like the CMS, which we most likely don't), and once that is answered that will probably answer a lot of the questions about setting up the Router class. What we know as modules aren't really a factor right now; those can be hard coded either into the template itself (the menu) or a component's layout.

So, at the basic level, what we actually NEED is something that can render our template and inject the layouts from our "components".

Using your example for the routing part, one of the later items from the roadmap is that we have some sort of user profile. So the route /person/:username should render a profile for the given user. Similarly, for /issue/:id/edit, the issue edit form should be displayed.

What does throw a fork into things is the hook receivers. Currently, those are tuned as direct entry points and don't really go through the tracker application at all. Should we integrate that into the core (we should I think), then the route for /hook/issueactivity would end up executing what is at https://github.com/joomla/jissues/blob/master/hooks/receiveissues.php now but wouldn't render anything.

[Chris-Jones-Gill]

If the project wants to use PHP for almost everything, which does make sense given that it is where the key competancies are for Joomla, then Twig would get my vote as the template engine.

Plus, I guess that in using the Joomla Framework we should use it to its fullest extent - and as it is an MVC framework it would probably go against the grain to implement 1/3 of the MVC (ie the View) using a separate framework like AngularJS.

I still like the idea of using AngularJS though, sort of separating the PHP server-side control (like the database stuff) from the JS presentation control.

The server/client (Joomla Framework/JS Framework) comms done through JSON (or XML) allowing the Joomla Framework to concentrate on the Data, and the JS Framework to concentrate on the rendering. This would provide a clean separation of responsibilities, where front-end designers don't need to get involved in the PHP code (they just get a nice JSON data package), and the backend developers don't need to involve themselves in the HTML/CSS/JS code (they just get a nice JSON data package). Designers can design, developers can develop and there is no bleed-through from either (e.g. no markup from the developers, and no database i/o from the designers) because the input and output from both is a JSON data package, and neither is concerned with what the other does with it.

Maybe that is not what the Joomla Framework is being built for, and I am being a bit precocious with my suggestions.

But, finally, if a PHP based end-to-end solution is the way to go, then Twig would fit the requirements really well.

Chris.

PS - Whatever the decision is I will happily support it. This is, after all, a discussion to find the best solution for the people who will do the work, and one that fits in with the projects (jissues and Joomla Framework) - democracy in action!

[mbabker]

Actually, you've got the right idea about the Framework. Ultimately, it would be nice if consumers of the code were using all of it, but the point of isolating and abstracting out the code is so that developers can use what they need and if they want to use something else, they're free to do so. Arguably, one could use the framework models and controllers with AngularJS handling the views if it were coded properly.

And to me, that's the great thing about the Framework; you're free to make a lot of the decisions for yourself.

[AmyStephen]

@mbabker - I think you're ideas are excellent and maybe, in the interest of time, simply selecting a good solution and using it might help later build in an Interface/Adapter approach later. I need to catch up and look more closely at https://github.com/joomla/jissues/blob/master/hooks/receiveissues.php -- sounds to me like you are creating a nice RESTful approach, resource oriented. If so, that's a good thing. =)

[AmyStephen]

An idea on an Interface https://gist.github.com/AmyStephen/5416271

[AmyStephen]

Hey @mbabker ! I'm sorry - I thought you opened an issue on the Framework for a template engine. (I just linked to it from the CMS thread.) I totally understand your need to pick a template engine and move on this. What I found confusing is why you would include someone else's Template engine in the Framework. If you do, then I'd go with more of an Adapter pattern. Here, use what you need, of course. No options are required.

[Chris-Jones-Gill]

Thought I would do a quick demo with AngularJS...

http://jissues.unknown.org.uk/ (one of my sandboxes, the link will be active until at least August 2013)

Click the 'fetch' button to retrieve the issues - the status will be 200 if successful, the table populated, and the raw data very full. Query limit is 60 times per hour (limited by github), but that should be enough for this demo.

It doesn't do much in the way of filtering (yet) but I might add that later. The only thing I've added is the 'accordion' style for when the issue title is clicked, which then shows the body of the issue.

It works from the open issues on this repo, pulling them as anon. user (i.e. no Oauth) direct from github - which is in JSON format - I've included the raw data so you can see how much info is available.

For completeness, and because the demo will not be around forever, I've included the code below

The meat of the AngularJS is

<script>
  var kwdtest = angular.module('kwdtest', ['ui', 'ui.bootstrap']);

    function getIssuesCtrl($scope, $http, $templateCache) {
      $scope.method = 'GET';
      $scope.url = 'https://api.github.com/repos/joomla/jissues/issues?state=open&per_page=100';

      $scope.fetch = function() {
        $scope.code = null;
        $scope.response = null;

        $http({method: $scope.method, url: $scope.url, cache: $templateCache}).
          success(function(data, status) {
            $scope.status = status;
            $scope.data = data;
          }).
          error(function(data, status) {
            $scope.data = data || "Request failed";
            $scope.status = status;
          });
      };

      $scope.updateModel = function(method, url) {
        $scope.method = method;
        $scope.url = url;
      };
    }
</script>

The template looks like this:

<html ng-app="kwdtest">
  <head>
    <link rel="stylesheet" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/themes/base/jquery-ui.css">
    <link rel="stylesheet" href="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.1/css/bootstrap-combined.min.css">

    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
    <script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.10.0/jquery-ui.min.js"></script>
    <script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.6/angular.js"></script>

    <script src="/angular/angular-ui.js"></script>
    <script src="/angular/ui-bootstrap-custom-tpls-0.3.0-SNAPSHOT.js"></script>    
    <script src="/angular/showdown.js"></script>

  </head>
  <body>
    <section name="jissues" ng-controller="getIssuesCtrl">
    <h2>jIssues</h2>
      <p>Fetch the open issues for https://github.com/joomla/jissues</p>
      <button ng-click="fetch()">fetch</button><br />
      <pre>Status: {{status}}</pre>
      <p>There are {{data.length}} issues.</p> 
      <table class="table table-bordered table-striped">
        <thead>
          <tr>
            <th class="nowrap hidden-phone" width="2%">ID</th>
            <th>Summary</th>
            <th width="5%">Priority</th>
            <th width="10%">Status</th>
            <th class="hidden-phone" width="10%">Category</th>
            <th class="hidden-phone" width="10%">Date Opened</th>
            <th class="hidden-phone" width="10%">Date Closed</th>
            <th class="hidden-phone" width="10%">Last Modified</th>
         </tr>
      </thead>
      <tbody>
        <tr ng-repeat="issue in data">
          <td class="center hidden-phone"> {{issue.number}} </td>
          <td class="hasContext">               
            <accordion>
              <accordion-group heading="{{issue.title}}">
                 {{issue.body}}
              </accordion-group>
            </accordion>        
          </td>
          <td class="center">
            <span class="badge badge-info"> 3 </span>
          </td>
          <td> {{issue.state}} </td>
          <td class="hidden-phone"> 
            <div ng-repeat="category in issue.labels">
              <span style="background-color: #{{category.color}}">
                &nbsp;
              </span> 
              {{category.name}}
            </div>
          </td>
          <td class="nowrap small hidden-phone"> 
            {{issue.created_at | date:'dd-MMM-yyyy'}} 
          </td>
          <td class="nowrap small hidden-phone"> 
            {{issue.closed_at | date:'dd-MMM-yyyy'}} 
          </td>
          <td class="nowrap small hidden-phone"> 
            {{issue.updated_at | date:'dd-MMM-yyyy'}}
          </td>
        </tr>
       </tbody>
      </table>

      <pre>Raw data: {{data | json }}</pre>

    </section>
  </body>
</html>

Chris.

[AmyStephen]

@KISS-Web-Design Very, very, very nice, Chris <3

[Chris-Jones-Gill]

Aw, shucks, thanks Amy :-)

[mbabker]

Looking nice, and I almost understand what's going on in there... LOL

On a serious note now, I've gotten the basic framework wired up and running, so it would definitely be nice to get the pages rendering soon.

[Chris-Jones-Gill]

Hi,

Which branch should I use to test this out? I am assuming it is the 'framework' branch, but you know what they say about assumptions!

I downloaded the 'framework' branch to my 'localhost', but that's where I stopped. Accessing the installation from a browser just gives me a '403 forbidden'.

I configured 'localhost' to be a brand-spanking-new Apache, MySQL, PHP setup - replicating the configuration of a basic shared host (Apache/2.2.22, MySQL 5.5.29 ,PHP 5.3.15).

Basically, I would like to know what to do next.

Like, do I need to install composer? Or are all the requires already loaded?

Do I need to install the framework requires manually, or will it happen (assuming they don't already exist) when the application starts?

Where are the settings/config file(s) for the database?

Anything else that you can think of?

Once I have it up and running locally, I can start looking at rendering something.

Cheers,

Chris.

[mbabker]

IIRC, you should be able to get running by checking out the framework branch (it has all dependencies in it right now, including symlinks to execute the app from the root instead of having to go into the www folder), setting up the database (use the etc/mysql.sql file for that), and setting up a configuration.php file at the root of the repo (you can use platformApp/configuration.example.php to get going). Assuming that works (going off memory here), you'll see the "Please select a project" text for the main landing page, but nothing else at the moment.

On Tue, Apr 23, 2013 at 2:32 PM, Chris Jones-Gill notifications@github.comwrote:

Hi,

Which branch should I use to test this out? I am assuming it is the 'framework' branch, but you know what they say about assumptions!

I downloaded the 'framework' branch to my 'localhost', but that's where I stopped. Accessing the installation from a browser just gives me a '403 forbidden'.

I configured 'localhost' to be a brand-spanking-new Apache, MySQL, PHP setup - replicating the configuration of a basic shared host (Apache/2.2.22, MySQL 5.5.29 ,PHP 5.3.15).

Basically, I would like to know what to do next.

Like, do I need to install composer? Or are all the requires already loaded?

Do I need to install the framework requires manually, or will it happen (assuming they don't already exist) when the application starts?

Where are the settings/config file(s) for the database?

Anything else that you can think of?

Once I have it up and running locally, I can start looking at rendering something.

Cheers,

Chris.

— Reply to this email directly or view it on GitHubhttps://github.com/joomla/jissues/issues/86#issuecomment-16880943 .

[mbabker]

With my latest commit to the framework branch, I've moved the sample config to the /etc folder and changed the application logic to load the configuration.php file from there as well. So simply cp etc/configuration.example.php etc/configuration.php and that part is handled. I also slightly updated the README with updated install instructions (you have to use the alternate path though which is a manual install).

[Chris-Jones-Gill]

Hi again,

checked out the latest framework branch, and configured the database.

I now get an HTTP 500 server error...

Doing a bit of debugging I found that the index.php (in /etc) tries to load the framework from

// Load the Joomla Framework require JPATH_BASE . '/vendor/joomla/framework/src/import.php';

but that folder (directory) does not exist, there is no 'src/import.php'

Changing the path to

// Load the Joomla Framework //require JPATH_BASE . '/vendor/joomla/framework/src/import.php'; require JPATH_BASE . '/platformApp/libraries/import.php';

seems to work (ie no errors or exceptions visibly thrown).

However the application still fails with a 'HTTP 500 server error' when it tries to Instantiate the application.

// Instantiate the application. $application = new Joomla\Tracker\Application\TrackerApplication;

I had a little poke around, but it seems that the file '/src/Joomla/Tracker/Application/TrackerApplication.php', which contains the TrackerApplication class is not loaded - I stuck an echo "application"; line at the top of the file (before the namespace, after the header), but nothing is displayed and the '500 error still shows up.

At this point I stopped, the issue could be with the autoloader, or as a result of the path change for import.php, or something else. As I don't know the codebase very well, I leave this note in the hope that it makes sense to someone and they can help me.

Regards,

Chris.

[b2z]

@KISS-Web-Design I still had no time to clone repo and to play around :( But will try to help. Tracker Application will not be instantiated because you changed the path to /platformApp/libraries/import.php. The strange thing is that you do not have src/import.php file. Do you have /vendor/joomla/framework folder?

[mbabker]

@KISS-Web-Design you shouldn't be loading from platformApp anymore, that's just the old code and will be going away once all the necessary stuff is converted over. The www/index.php file sets JPATH_BASE to the root of the repo then should load the Composer autoloader from vendor/autoload.php then should boot up the Framework by calling the vendor/joomla/framework/src/import.php file.

Unless I'm misunderstanding how Composer works and how the Composer dependencies are committed to the repo, you shouldn't need to do anything special. @realityking or @dongilbert might be able to clear that up for me. But, if for some reason you do have to install the Composer stuff yourself, the instructions in the README at https://github.com/joomla/joomla-framework should help.

[Chris-Jones-Gill]

@mbabker @b2z Thanks guys, I get that the framework should boot up from

vendor/joomla/framework/src/import.php

but that does not exist in the repo (framework branch) see:

https://github.com/joomla/jissues/tree/framework/vendor/joomla

which only contains the 'framwork' folder (with a green folder icon?? is it a symlink?), clicking on it does not open anything or have any effect. Screenshot:

So the only place that import.php exists in that branch is in the platformApp structure, which is why I tried using it - copying it to 'framework/src/import.php' won't work due to other dependancies in that import.php file that are referenced from the DIR it is located in.

The real issue is the missing folder and file(s) under the 'vendor/joomla/' structure.

Regards,

Chris.

[b2z]

@KISS-Web-Design try to grab it manually ;)

[mbabker]

I guess you'll have to do the Composer install then. I woulda thought that since I committed that stuff to the repo it would've been good for all. Shows what I get for thinking.

[Chris-Jones-Gill]

Composer install, and manually pull it all in is the way to go then :-)

Will do that later, or tomorrow, for some reason clients want me to do some work for them before they pay me???

Things would be so much easier with a large lottery win (just a couple of million, I' not greedy), loads of free time to do fun stuff (like this) without having to worry about paying bills or buying food.

[elkuku]

I finally found some time to clone the new repo ;)

When I first cloned the repo and ran a composer install I got this:

$ composer install
Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating autoload files

  [RuntimeException]
  Could not scan for classes inside
  ".../vendor/joomla/framework/src/Joomla/Compat/JsonSerializable.php"
  which does not appear to be a file nor a folder

hu... So I went on, deleted that empty /vendor/joomla/framework folder, and now composer install did its job.

Would you mind to explain how you managed to push an empty folder to a git repo ? Is it a submodule without its .gitmodules file ?

Next thing I hit was a missing ucfirst resulting in a "wrong path" - seems that our lead coder is now running a widows® "OS" ... :see_no_evil:

I will pick up the CLI scripts and "refactor" them to get possible contributors up and running more quickly. Nice job so far ;)

[mbabker]

No Windoze here (well, for this project, I still fire it up for SQL Server testing on a rare occasion). Where was the missing ucfirst at?

It looks like the Composer install is considered a git subproject in my laptop and when you look at the commit history (see https://github.com/joomla/jissues/commit/5c076bf618d8f37221b81c6885a9ef3f1c465d44). So, maybe that's how it got committed empty.

[elkuku]

The wrong path was at f76f26284caf1d443d7b4e3702c1effe6ee4c24f which should work perfectly on a non case sensitive filesystem - sorry for the wrong assumption :P

For the installation issue.. I still have to figure out how Composer works. For now it seems to be required to run a composer install after cloning the repo (@todo update the readme if true). This seems to be also required for a "core framework application" . So since the /vendor/autoload.php and /vendor/composer/* files are already present after cloning the repo, those will be modified... not good. --- Could it be that only the composer.lock file should be committed ?

Think I will to start some coding now ;)

[mbabker]

I'll dig a bit more, but I think you're right in that we should just commit the composer.lock file and git ignore the entire vendor directory since we don't have any files manually lumped in there.

Maybe for the CLI installer, we could include the composer.phar file from http://getcomposer.org/download/ and trigger it in the CLI?

[AmyStephen]

Admittedly, I did not read all of the above. But, my sense is you are working to hard. Why not create a composer.json with the packages needed and use the "standard" approach?

https://github.com/Molajo/Standard/tree/master/Vendor/Molajo/Cache#install-using-composer-from-packagist

[mbabker]

There is a composer.json with that info. Some n00b to working with Composer though didn't realize that everyone would have to do a composer install locally even though he committed everything from his local composer install to the repo. So, to make it a little easier for folks, I'm thinking that the composer install can be run from the CLI installer we use to set up the database (and eventually, once the code exists again, create the admin user).

[AmyStephen]

@mbabker I put a comment out on Twitter and will look around a bit, but I think what folks do is use Phing (or the like) and create their zips from the composer install process. That can allow you to also remove those gnarly .git files that are enormous and possibly remove the tests, if appropriate. I'll look around.

[elkuku]

I'm not sure how to run the composer from the CLI installer, since the installer requires the framework already being present.. I think right now we need a "more or less" simple setup for developers to start contributing. IMHO that should be something like:

1. Clone the joomla/jissues repo and switch to the "framework" branch.
2. Run composer install
3. Run the CLI installer script(s).
4. Contribute ;)

There seems to be some interest at least (and on topic) in the template engine to use...

[mbabker]

Said 3 step approach works for me.

Can we get the template engine implemented then if there's a general idea on what to use? It looks like Twig is the preferred PHP solution and there's some interest in AngularJS. I know it's going to be hard for me to work on converting things like the JHtml helpers without knowing how things will be output. And the last thing anyone here wants is someone like me trying to plug either Twig or AngularJS into the code.

[Chris-Jones-Gill]

Just pulled the latest framework branch and ran composer, which loaded all the framework files, and checked in a browser. Output: Please select a project :-) it works!

Went to the cli folder in a terminal, > php tracker.php

Output: ERROR: Missing class: CliApp\Command\Help\Help

Seems that the help.php file is empty, no class or methods

not sure what the output from tracker.php should be, but without the help class (and at least the ::execute method) nothing will work.

I added

namespace CliApp\Command\Help;

class Help 
{
    public function execute()
    {
    }
}

to the help.php file, just to get the tracker.php to stop throwing an exception, and ran > php tracker.php again. Output: No errors, no output at all, don't know if this is correct (for the current state of the cli tracker.php) or it's failing silently, or doing something silently.

Anyway, as I now have the application running in a browser, I can start looking at getting some data out of the app and rendering it in a useful way.

I may be some time...

[mbabker]

Woohoo!

If you go to /markdownpreview in your browser, that should give you the page we have to preview the output you get with the GitHub Markdown rendered. That's probably the best page to work with in terms of doing template work as it'll let you quickly see a lot of styling.

[Chris-Jones-Gill]

There doesn't seem to be any routing for /markdownpreview it just gives a 404 error

Not Found

The requested URL jissues/index.php was not found on this server.

I can access the page directly by appending /src/Joomla/Tracker/Components/Tracker/View/MarkdownPreview/tmpl/default.php
to the root url

there is no formatting applied to the file contents (obviously), as there is no stylesheet or markdown parser included.

But what I am really after is an output from an application function [like getIssues($options) for example] which runs a query on the database according to the $options. So I can call the function (with options/parameters) and it returns a string, or array, or json object, or whatever, and from that I can build an interface UI around the defined options and expected results.

Also an entry point for sending any changes or additions back to the database [like setIssues($options) for example] would be useful for testing (eg workflow= get open issues, get single issue, add comment, send comment, get single issue, check to see if the new comment has been added)

[mbabker]

There's a .htaccess at the repo root that's supposed to by symlinked to www/.htaccess which works fine at my computer and picks up the proper routing. Of course, I'm not a .htaccess pro (that one's copied from Louis' pull tester repo) and it may be FUBAR for others.

I think if we disable all of the stuff dealing with the session and the project ID check in the issues list view, we can get the basic list view rendering which will pull from the database. I can work on that at some point today.

[Chris-Jones-Gill]

Ah, OK. Didn't see that sneaky little .htaccess file.

As I am using a MAC with the AMP stack hand-rolled (not using MAMP) I needed to add

RewriteBase /~username/site/

to .htaccess before RewriteCond %{REQUEST_FILENAME} !-f to tell it where my installation lives.

Where /~username/site/ was MY username and the name of the directory I gave to MY jissues installation. Anybody else re-creating this will need to use their names.

For completeness, and for my future reference (or for others, if needed) the /etc/apache2/httpd.conf file must be setup correctly too, these are taken from my working setup. The following codeblocks should be added, or existing blocks edited, for this to function as expected

<Directory />
    Options FollowSymLinks
    AllowOverride All
    Order deny,allow
    Deny from all
</Directory>

The following block in the default httpd.conf file has lots of comment lines separating each command line.

<Directory "/Library/WebServer/Documents">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

The key changes from a default file are the AllowOverride All commands, which are set to AllowOverride None by default. Missing commands should be added in the same order as given above.

Editing httpd.conf requires root, so from Terminal use sudo nano /etc/apache2/httpd.conf

After making any changes to httpd.conf you must restart apache sudo apachectl restart for the changes to take effect.

After all that, going to /markdownpreview works as expected. Phew!

Chris.

[mbabker]

In 46e8a14200fbec2dfaf3203824a1316e1a49ded5 I've disabled the code that handles the project selector and set a temporary default to the CMS tracker.

If you do an install using the master branch and run the CLIs to retrieve issues and comments for the CMS then switch back to the framework branch, that will give you a populated database to work with including all the data we're currently capable of handling (issues list, issue details view including the activity stream and comments).