[#86] - Select and implement a template engine (or The issue to discuss everything Framework refactoring)
- Closed
- 18 Jun 2013
- Medium
- Build: master
- # 86
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).
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.
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 GitHub#86 (comment)
.
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.
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.
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? :)
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.
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.
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.
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?
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.
Any support for an Interface-first approach to this question?
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
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.
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?
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.
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!
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.
@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. =)
An idea on an Interface https://gist.github.com/AmyStephen/5416271
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.
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}}">
</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.
@KISS-Web-Design Very, very, very nice, Chris <3
Aw, shucks, thanks Amy :-)
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.
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.
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 useplatformApp/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 GitHub#86 (comment)
.
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).
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.
@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?
@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.
@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.
@KISS-Web-Design try to grab it manually ;)
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.
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.
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" ... 
I will pick up the CLI scripts and "refactor" them to get possible contributors up and running more quickly.
Nice job so far ;)
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 5c076bf). So, maybe that's how it got committed empty.
The wrong path was at f76f262 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 ;)
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?
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?
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).
@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.
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:
- Clone the joomla/jissues repo and switch to the "framework" branch.
- Run
composer install - Run the CLI installer script(s).
- Contribute ;)
There seems to be some interest at least (and on topic) in the template engine to use...
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.
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...
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.
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)
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.
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.
In 46e8a14 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).
There is an updated readme.md file that explains how the CLI script is supposed to work now (similar info should have been displayed when calling the script with no arguments - late night work... - sorry for the confusion.
So there is no need to switch branches, but that's also an option ;)
I think you fixed that up while I fixed up the issues list view. Our paths hadn't crossed yet 
I haven't looked at the updated retrieve CLIs, but in the older versions, I had an option to authenticate to GitHub and the option would use the credentials you store in your configuration.php file. So, try filling in the github options in there and you should be good to go with that.
Should work like this.
The script actually displays the current rate limit. So if, after filling in your credentials, you still get "60" we might have a problem with J\Github's basic auth :(
OK, got it working... to a point...
The list is pulled, but the links to each issue result in Layout Path Not Found for /issue/60
Also, the buttons that submit the form with options causes a Unable to handle request for route `index.php`. on my localhost
This can be fixed by adding (inside the <?php ?> before the <form action...)$web_root = "http://".$_SERVER['HTTP_HOST'].dirname($_SERVER['PHP_SELF'])."/";
and changing<form action="<?php echo htmlspecialchars('index.php'); ?>" method="post" name="adminForm" id="adminForm" class="form-inline form-search">
to<form action="<?php echo htmlspecialchars($web_root); ?>" method="post" name="adminForm" id="adminForm" class="form-inline form-search">
If others have the same issue I can submit a PR
Anyway, I can start looking at the template now.
Is there any preference for the template location and folder structure?
I think they should be stored outside of the src/Joomla/Tracker/Components/Tracker/ path, as a stand-alone item - maybe in a directory called templates?
Then the View(s) can include the template file required for whatever view it will display (issue list, single issue, etc), the template names can be defined in an ini file (or in the database, but that would require an admin function)
ISSUE_LIST_TEMPLATE_NAME="issuelist.html"
SINGLE_ISSUE_TEMPLATE_NAME="singleissue.html"
This makes it simple to try different template ideas without touching the PHP code.
Happy to hear other thoughts on this though.
The layouts aren't found because they aren't present yet (I actually haven't converted over the single view, but because the high level generic models and views are in play, the code thinks it can do something). The form doesn't work because I hadn't worked on that yet either. Congrats, you're running into known issues quicker than I can get past them 
The CMS based template is at www/joomla right now. Feel free to do with it as you please. As for the view layouts, right now they're coded into the same directory as the view class (since that's how we've always done business, felt easier to just keep going with that). If that doesn't work for some reason, give a shout and we'll figure out what works best.
Ok, I have managed to implement Twig using Twiggy. I slightly modified it and templates are working now ^_^. Currently it is a brute implementation just to show how it could work. Templates are in /www /default folder.
You can have a look on it in my twig branch. Please note that you will need a Twig. I have updated composer.json so you can simply run composer install to get a Twig. Do not forget to delete composer.lock file before the install.
The main thing that I still do not understand completely, how to run a PHP code inside the templates. As far as I understand we can not simply run use Joomla\Language\Text; :( There are some Twig tools, but I am not a template engines specialist, so we will need some help here...
I'll defer to those who've used the tool before for advice here, but so far, what you've got doesn't look all that difficult to implement.
I've cloned and updated the framework branch = https://github.com/KISS-Web-Design/jissues
Added route for /ajsissues which is the AngularJS template. Use that route to see the nicely formatted output.
Click the Fetch button to update the table.
Default view changed to output a JSON object that matches the required fields, so you will see a messy output from the root. But it is useful for debugging, which is why I've left it accessible.
The Fetch button calls the default view, which returns the JSON object, and then processes that object.
TODO:
- Tidy up the output, add more (optional) fields
- Add open/closed filter
- Add sortby filter
- Get comments from backend, View comments
- Create comment, send to backend
There are many more TODO's, but that will do for now.
I've kept the view in the Application/Tracker path to minimise the required changes, and to make it easier to see what is happening (hopefully)
Chris.
I just ran the CLI retrieve and with credentials, I'm still getting the 60 hit API limit. So, something isn't happening to get the credentials loaded in.
Glad I'm not the only one...
Could you please try the following snippet to confirm, that the tiny CLI script is not to blame..
create /foobar.php
include 'vendor/autoload.php';
$options = new \Joomla\Registry\Registry;
$options->set('api.username', 'CHANGE_ME');
$options->set('api.password', 'CHANGE_ME');
$gitHub = new \Joomla\Github\Github($options);
$rate = $gitHub->authorization->getRateLimit()->rate;
echo $rate->limit;
// Expected; 5000
// Actual: 60
and then change it to
include 'vendor/autoload.php';
$options = new \Joomla\Registry\Registry;
$options->set('api.username', 'CHANGE_ME');
$options->set('api.password', 'CHANGE_ME');
$transport = \Joomla\Http\HttpFactory::getAvailableDriver($options, 'curl');
$http = new \Joomla\Github\Http($options, $transport);
$gitHub = new \Joomla\Github\Github($options, $http);
$rate = $gitHub->authorization->getRateLimit()->rate;
echo $rate->limit;
// Expected; 5000
// Actual: 5000
The second one will obviously only work with cURL enabled.. both should give you 5000 while the first example is using the "default transport"...
This might require a separate issue ;)
It's something to do with the socket connector. Using the second snippet, I tested all three connectors and cURL and Stream both returned 5000 (as expected) while Socket returned 60 (in error). So, yep, something's not quite right in the Framework code.
BTW where do we want to store external libraries like Twiggy for example. Currently I put it under the libraries dir in the root of the project. May be want them under the Tracker dir and namespaced?
Dmitry, external libraries would typically go in the vendor directory for a composer project, if they are installed via composer. You wouldn't want to namespace them to fit with our code structure, simply because then it becomes impossible to update.
@dongilbert Don, that's for sure. But I mean libraries which are not from a composer source, for example Twiggy. Where is the best place to locate such code? Currently we have some dirs outside src dir so I thought libraries should also go outside.
Well in that case, I would search packagist.org for a Twig package instead of using one outside of composer. There are several available. I'm not sure why we aren't just using Twig itself.
The reason I'm advocating this is because we really need a single way to handle 3rd party libraries to help keep things simple and manageable.
—
Sent from Mailbox for iPhone
On Mon, Apr 29, 2013 at 9:24 AM, Dmitry Rekun notifications@github.com
wrote:
@dongilbert Don, that's for sure. But I mean libraries which are not from a composer source, for example Twiggy. Where is the best place to locate such code? Currently we have some dirs outside
srcdir so I thoughtlibrariesshould also go outside.Reply to this email directly or view it on GitHub:
#86 (comment)
What's the benefit of using Twiggy versus using Twig direct?
Well it is some kind of the abstraction layer (it is one class and config file.). It helps to initialize and configure Twig and also provides some other features. We can also extend Twig using it. IMO using direct implementation not the best approach. Who knows, what changes will be in Twig, but using this layer will help us to be more independent and decoupled from Twig.
That might be the case, but if so think we should build an abstraction layer ourselves rather than relying on one built for CodeIgnitor (Since we don't what changes will be introduced in that software either). One that fits our needs perfectly that we control and can serve as a basis for Joomla! Next. Also, Twig goes through a lot of trouble to provide backwards compatibility. Read the article here:
http://fabien.potencier.org/article/68/about-symfony-stability-over-features
Focus on this paragraph:
"I also want to point out that I've tested this approach with Twig. Twig version 1.12.3, released last week, is enterily backward compatible with Twig 1.0, released two years ago (to be fair, we made one mistake in 1.2 if I remember correctly). Of course, Twig is much smaller than Symfony, but if you take each Symfony component as an individual library, then the same approach can be applied. Last year, I started to work on Twig 2.0 because I thought that introducing some great features was not possible with the current architecture, but with some more work, I did introduce everything I wanted in Twig 1 without breaking backward compatibility. That's a big win. And that's probably one of the reasons why so many projects plan to use Twig nowadays (Drupal, eZPublish, Magento2, ...): Twig evolves fast but in
a stable way. By the way, that's why namespaces won't be introduced in Twig anytime soon: we don't have a need for them."
So, I think it will be possible to build a very simple abstraction system which handles config in the same way as the rest of our application.
Also, I think we should be able to easily offer support for other templating engines. So, to provide that, I think we should put these items in a view renderer. Something like:
namespace Joomla\View\Renderer;
class Twig extends \Twig {}
Then we could also have:
namespace Joomla\View\Renderer;
class Mustache extends \Mustache {}
And so on and so forth. I really like the Dust templating engine, but it's 5.4 only for now, though there are plans to backport and release a 5.3 version as well, which would be awesome.
Don I agree. But I was thinking about JTracker implementation and correct me if I am wrong, you are talking about joomla-framework? BTW Twiggy is not coupled with the Codeigniter, so it can be used without any problems. I took it only as an example how Twig could be implemented ;)
I have just copied my (working) local installation upto a live server
http://jissuesajs.unknown.org.uk/ajsissues
but am getting the Layout Path Not Found message.
I have dug around a bit, and sent some debug messages to the console. What I see is the variable $path in the render function of the class AbstractHtmlView in the non-working version is boolean false, but in the working version it is a string of the location of the view template.
working local version
class AbstractHtmlView extends AbstractView - function render $path
/Users/chris/Sites/jissues/src/Joomla/Tracker/Components/Tracker/View/Ajsissues/tmpl/default.php
non-working live server version
class AbstractHtmlView extends AbstractView - function render $path
false
Can someone point me in the right direction for sorting this out - it may be something really simple (hopefully), but I can't see where this $path variable comes from, so I'm a bit stuck at the moment.
If you go to the live version http://jissuesajs.unknown.org.uk/ajsissues and use the browser tools to inspect and look at the console you will see a number of debug messages that might help.
What it looks like on my local machine
1. Before calling the backend for the data
2. After calling the backend for data
The JSON object that the modified default view outputs looks like this
It would be nice to get the live version working, as there is nothing better than a live demo to explain what is happening.
Thanks in advance for any helpful suggestions.
Chris.
I am talking about framework, yes. But now that the Tracker is using the framework it's very relevant to the discussion. So what we build would be the specific implementation for the Tracker, but I think it's possible to build something generic enough and still give us what we need on the framework. So, the tracker will be the test bed to try out the code and get it refined before pushing it upstream to the framework.
Also, the Twiggy code you linked to is (without your modifications) bound to CI. It has a private CI property and also uses the CI get_instance() function to pull in the global CI instance to the class.
So, it's possible that Twiggy would be a good starting point for a Tracker/Framework Twig abstraction class. But we must remember, it's MIT licensed, and the Framework currently does not accept MIT licensed code into the core. (Someone correct me if I'm wrong, but I'm pretty certain that this is the case.)
(I wish GitHub would parse the email message and retain formatting. Otherwise, responding via email with anything more than a cursory note is pretty useless.)
I look at this code as a place where we can experiment. And if we find something that the Framework is lacking in, why not build it and submit it (in this case, the renderer that Don's talking about).
Grabbed the latest framework branch, and tried to retrieve issues with github authentication, with the following result:
Joomla! Tracker CLI Application
1.1
Retrieve Issues
1) Joomla! CMS 3 issues
2) J!Tracker Bugs
Select a project: 1
Do you wish to authenticate to GitHub? [y]es / [n]o :y
GitHub rate limit:...
ERROR: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
#0 /Users/chris/Sites/jissuesfm/vendor/joomla/framework/src/Joomla/Http/Http.php(175): Joomla\Http\Transport\Curl->request('GET', Object(Joomla\Uri\Uri), NULL, NULL, 120, 'JGitHub/2.0')
#1 /Users/chris/Sites/jissuesfm/vendor/joomla/framework/src/Joomla/Github/Package/Authorization.php(234): Joomla\Http\Http->get('https://chris.j...')
#2 /Users/chris/Sites/jissuesfm/cli/CliApp/Command/Retrieve/Retrieve.php(201): Joomla\Github\Package\Authorization->getRateLimit()
#3 /Users/chris/Sites/jissuesfm/cli/CliApp/Command/Retrieve/Issues.php(48): CliApp\Command\Retrieve\Retrieve->displayGitHubRateLimit()
#4 /Users/chris/Sites/jissuesfm/cli/CliApp/Application/TrackerApplication.php(149): CliApp\Command\Retrieve\Issues->execute()
#5 /Users/chris/Sites/jissuesfm/vendor/joomla/framework/src/Joomla/Application/AbstractApplication.php(104): CliApp\Application\TrackerApplication->doExecute()
#6 /Users/chris/Sites/jissuesfm/cli/tracker.php(38): Joomla\Application\AbstractApplication->execute()
#7 {main}
Seems that setting the api.username and api.password causes this issue
if ($resp == 'y' || $resp == 'yes')
{
// Set the options
$options->set('api.username', $this->application->get('github.username', ''));
$options->set('api.password', $this->application->get('github.password', ''));
$this->application->debugOut('GitHub credentials: ' . print_r($options, true));
}
as that is the only difference between answering [y] or [n] to
Do you wish to authenticate to GitHub? [y]es / [n]o :
because [n] works, albeit with a rate limit of 60, but [y] fails as above.
Additionally I am still getting the Layout Path Not Found message on my live server - any ideas anyone?
Chris.
The server might be case sensitive. If the app is looking for a file path with a leading uppercase but the file path is all lowercase, that might cause an issue.
Did you set the github.username and github.password config items? Can you enable the CLI's debug and see if it outputs your credentials if it did so?
Looking at your branch, you might have issues with the case sensitivity and a duplicated path. I see in the src/Joomla/Tracker/Components/Tracker/View folder an Issues and issues folder, and in both folders the file name starts with a leading lowercase (while the class name is uppercase). Also, the ajsissues folder should be renamed to Ajsissues since the system is looking for leading capitals on the folder names except for the tmpl folders in the views.
@mbabker Thanks,
http://jissuesajs.unknown.org.uk/ajsissues
now works :-)
You can now see the AngularJS template in action, I will update my fork soon so the working server version matches the version in github.
The template is pretty simple, and I have explained it below as best I can (hope it helps somebody).
TL;DR
The data is a JSON object from the http://jissuesajs.unknown.org.uk/ url, the {{ ????? }} are data-bindings to the fields in the data. Anything beginning with ng- is an AngularJS directive.
See http://docs.angularjs.org/guide/overview for the official AngularJS developer docs
Details...
<html ng-app="kwdtest">
ng-app tells AngularJS that it is an AngularJS app (the ng- prefix is AngularJS specific)
<h1>KWD test app</h1>
<hr>
<section name="jissues" ng-controller="getIssuesCtrl">
<h2>jIssues</h2>
<p>Fetch the issues</p>
<button ng-click="fetch()">fetch</button><br />
ng-controller="getIssuesCtrl" defines the controller function as getIssuesCtrl (see below for the JS bit)
ng-click="fetch()" defines the function within the controller that is run when the button is clicked
<pre>Status: {{status}}</pre>
<p>There are {{data.length}} issues.</p>
{{status}} is a data-binding that is a result of the fetch()
{{data.length}} is also a data-binding (for data), but has the AngularJS .length method appended - which returns the number of records received in the JSON object
<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">
ng-repeat="issue in data" is a foreach loop, where issue is each record in the JSON data object
<td class="center hidden-phone"> {{issue.number}} </td>
{{issue.number}} is a databinding to the current issue in the loop, with the field number from that issue being returned.
If you look at the raw data you can see each field with each issue within the JSON object.
<td class="hasContext">
<accordion>
<accordion-group heading="{{issue.title}}">
<div ng-bind-html-unsafe="issue.body"></div>
{{issue.title}} is a databinding to the current issue in the loop, with the field title from that issue being returned.
ng-bind-html-unsafe="issue.body" is a directive that tells AngularJS to display all the HTML in the body field. This is inherently not a safe thing to do, however as I know that the data is coming from a safe source (the jissues database, via all the safety methods in the framework and the jissues PHP) I have displayed it as HTML, and not as a string.
</accordion-group>
</accordion>
</td>
<td class="center">
<span class="badge badge-info"> 3 </span>
</td>
<td> {{issue.state}} </td>
{{issue.state}} is a databinding to the current issue in the loop, with the field state from that issue being returned.
<td class="hidden-phone"> <div ng-repeat="category in issue.labels"><span style="background-color: #{{category.color}}"> </span> {{category.name}} </div></td>
ng-repeat="category in issue.labels" is a foreach loop that loops through the labels that the issue has,
{{category.color}} and {{category.name}} are data-bindings to the color and name fields within the category.
There are no labels (they are not currently available from the database).
<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>
{{issue.created_at | date:'dd-MMM-yyyy'}} is a data-binding to the created_at field, with an additional instruction that it is a date, and to display in the format 'dd-MMM-yyyy
These fields are not currently returned in the JSON object.
</tr>
</tbody>
</table>
<pre>Raw data: {{data | json }}</pre>
</section>
{{data | json }} is the final data binding, and displays all of the fields in the data JSON object, the | json is an additional instruction to AngularJS to display data in formatted JSON
The AngularJS code
var kwdtest = angular.module('kwdtest', ['ui', 'ui.bootstrap']);
This defines the application, and must match the name defined by ng-app (see above) and defines the dependencies, in this case 'ui', 'ui.bootstrap'
function getIssuesCtrl($scope, $http, $templateCache) {
defines the entry point for the controller getIssuesCtrl which the ng-controller specified as the controller for this app (see the HTML above)
$scope.method = 'GET';
$scope.url = 'http://jissuesajs.unknown.org.uk/';
sets two variables to be used within this $scope - similar to $this in PHP
$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;
});
};
This is the function that runs when the fetch button is clicked.
It runs the AngularJS $http service, which has 2 possible outcomes success and errorsuccess returns the $scope.status and $scope.data which is the data-bindings {{status}} and {{data}} used in the HTML above. A successful result will have a status of 200.error inserts "Request Failed" into the $scope.data variable, and that will be displayed in the rawdata section of the HTML by the data-binding {{data | json}}. The status of the attempt to connect to the $scope.url with the $scope.method method is also returned.
The url http://jissuesajs.unknown.org.uk/ is the default view of the jissues application, and contains the following PHP
foreach ($this->items as $i => $item) :
$myArr['number'] = $item->id;
$myArr['title'] = $item->title;
$myArr['body'] = $item->description;
$myArr['github_id'] = $item->gh_id;
$myArr['priority'] = $item->priority;
$myArr['state'] = $item->status_title;
$itemArr[$i] = $myArr;
endforeach;
echo json_encode($itemArr);
Which builds the JSON object using the existing $this->items and outputs it using an echo
This is to make it easier to see what is going on, and is not intended for production code.
Chris.
The errors in the CLI script might be related to:
- Please ensure that PHP's OpenSSL support is enabled on your system.
This seems to be somewhat painful on Windows systems (read the comments..). - Everything else related to https is set up correctly on your server.
Please have a look at the server log files !! - It is recommended (strongly) to use PHP's cURL support.
@todo run a system check to ensure the server meets the requirements (user experiencing problems might contribute a check)
re: CLI errors
php tracker.php retrieve issues -v
----------------------------------------
Joomla! Tracker CLI Application
1.1
----------------------------------------
----------------------------------------
Retrieve Issues
----------------------------------------
1) Joomla! CMS 3 issues
2) J!Tracker Bugs
Select a project: 1
Do you wish to authenticate to GitHub? [y]es / [n]o :y
DEBUG GitHub credentials: Joomla\Registry\Registry Object
(
[data:protected] => stdClass Object
(
[api] => stdClass Object
(
[username] => [redacted]
[password] => [redacted]
)
)
)
DEBUG Joomla\Http\Transport\Curl
GitHub rate limit:...
ERROR: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
#0 /Users/chris/Sites/jissuesfm/vendor/joomla/framework/src/Joomla/Http/Http.php(175): Joomla\Http\Transport\Curl->request('GET', Object(Joomla\Uri\Uri), NULL, NULL, 120, 'JGitHub/2.0')
#1 /Users/chris/Sites/jissuesfm/vendor/joomla/framework/src/Joomla/Github/Package/Authorization.php(234): Joomla\Http\Http->get('https://chris.j...')
#2 /Users/chris/Sites/jissuesfm/cli/CliApp/Command/Retrieve/Retrieve.php(201): Joomla\Github\Package\Authorization->getRateLimit()
#3 /Users/chris/Sites/jissuesfm/cli/CliApp/Command/Retrieve/Issues.php(48): CliApp\Command\Retrieve\Retrieve->displayGitHubRateLimit()
#4 /Users/chris/Sites/jissuesfm/cli/CliApp/Application/TrackerApplication.php(149): CliApp\Command\Retrieve\Issues->execute()
#5 /Users/chris/Sites/jissuesfm/vendor/joomla/framework/src/Joomla/Application/AbstractApplication.php(104): CliApp\Application\TrackerApplication->doExecute()
#6 /Users/chris/Sites/jissuesfm/cli/tracker.php(38): Joomla\Application\AbstractApplication->execute()
(1) with debug enabled I can see the github credentials, and they are correct
(2) OpenSSL is enabled
from phpinfo:
OpenSSL support enabled
OpenSSL Library Version OpenSSL 0.9.8r 8 Feb 2011
OpenSSL Header Version OpenSSL 0.9.8r 8 Feb 2011
(3) cURL is enabled
from phpinfo:
cURL support enabled
cURL Information 7.24.0
Age 3
Features
AsynchDNS Yes
Debug No
GSS-Negotiate Yes
IDN No
IPv6 Yes
Largefile Yes
NTLM Yes
SPNEGO No
SSL Yes
SSPI No
krb4 No
libz Yes
CharConv No
Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, pop3, pop3s, rtsp, smtp, smtps, telnet, tftp
Host x86_64-apple-darwin12.0
SSL Version OpenSSL/0.9.8r
ZLib Version 1.2.5
(4) php-curl is installed, and working
I created a simple curl test, taken from http://www.php.net/manual/en/curl.examples-basic.php
<?php
$ch = curl_init("http://kisswebdesign.co.uk/");
$fp = fopen("index.php", "w");
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
curl_close($ch);
fclose($fp);
?>
which works fine, and downloads the file without any errors
(5) php openssl is installed and working
I created a simple test page, taken from http://uk3.php.net/manual/en/book.openssl.php#91210
<?php
if (isset($_SERVER['HTTPS']) )
{
echo "SECURE: This page is being accessed through a secure connection.<br><br>";
}
else
{
echo "UNSECURE: This page is being access through an unsecure connection.<br><br>";
}
// Create the keypair
$res=openssl_pkey_new();
// Get private key
openssl_pkey_export($res, $privatekey);
// Get public key
$publickey=openssl_pkey_get_details($res);
$publickey=$publickey["key"];
echo "Private Key:<BR>$privatekey<br><br>Public Key:<BR>$publickey<BR><BR>";
$cleartext = '1234 5678 9012 3456';
echo "Clear text:<br>$cleartext<BR><BR>";
openssl_public_encrypt($cleartext, $crypttext, $publickey);
echo "Crypt text:<br>$crypttext<BR><BR>";
openssl_private_decrypt($crypttext, $decrypted, $privatekey);
echo "Decrypted text:<BR>$decrypted<br><br>";
?>
which outputs
UNSECURE: This page is being access through an unsecure connection.
Private Key:
-----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDoIY1O2cbcS8hAG7e9mixNbh731+Xtw/8FbFx3AJ1tjMFFvnJV eo/dwExmQUir+O567JxZZDR6ZyKoSFPDjirhUuytvhtx03pqA+BC1JdkSNfTjOGz rAwinci5w9mDe2RBfA4hohYKkuLZpi+yUHZcJKeW8tfpQKY1pwJJv2H9KQIDAQAB AoGAAhmznqAH1Zx17maRzgxkFDtH2nRAp1sbpp/pYkZGJmScpxXnEPDv9lC0IES8 9JlnBwO3EnP+qZDfVmh5IY7awnTFL1GadkUv4B6il0PVlpe/YNJ+KWbea75JZtOk ct4B5+d2xHK/2+gdK7NOagLCNhtUAgn/84pvljhSnqTHsQUCQQD22QxEE665Minv 1dlqSkBaYWkmA/UzsKrXHgvF3szPeqqzXlWBKaOM5G5TkQk3+WsyAi7Odg5bEIZY ZfNtlh+zAkEA8LzR6zsweaAvdAD1Gn/lnwqs8JYgdB3m2Zlc0BmTgbQYkSOIIMpy QmYbrvRuvbwHKdrHi5A+4oH5mV1SsX1hswJBALVguIWRHNJRjMUAkjdqhayjZNqd D9/CUVWtayMiWcWeMa2IhDVa/iS5eGOI74gkieJ9/hyQXG4HT1/G0b5VD8cCQGcH aI/T9RsYgzaSclO1CQDYAMu2dI09ft8B08b8KzUHbrwvCMN/4QapzI9D7WEmZ6py B5SjV0Z5eek5F3r+viECQQDzU/QwBUgtWvPnctULN6Od1xFDmlSqwrhYsG09KpGn lWHX4KMQMUcVbvijLHpO21WWfuYjXv/hBqHQ8+ChMpGO -----END RSA PRIVATE KEY-----
Public Key:
-----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoIY1O2cbcS8hAG7e9mixNbh73 1+Xtw/8FbFx3AJ1tjMFFvnJVeo/dwExmQUir+O567JxZZDR6ZyKoSFPDjirhUuyt vhtx03pqA+BC1JdkSNfTjOGzrAwinci5w9mDe2RBfA4hohYKkuLZpi+yUHZcJKeW 8tfpQKY1pwJJv2H9KQIDAQAB -----END PUBLIC KEY-----
Clear text:
1234 5678 9012 3456
Crypt text:
µUØÄZÄ24Ú¹q™)@g$¥›²MŸ1¥£&™ª£§ÌÍpC(+Xâò¦Ut-J¢9Öcœdócu!Kãã]h7&ÝsŒÜ’é‚~çrbT°°H’®«¯tí.YÂÈ) µþFÊübZ‹¨ 9ÄëK@gsQ(ô³ÓS
Decrypted text:
1234 5678 9012 3456
(6) PHP error logging is on, no errors are reported in the logs (checked syslog, apache error_log) - changed the php.ini to redirect errors to its own log file. No errors reported.
Hope all this explains my localhost server setup (Mac, Apache, PHP, mySQL -- hand rolled, not MAMP install), and may point the way in diagnosing the problem I am having with the CLI
Chris.
re: CLI errors
I believe the issue arises when using https. Could you run your tests using a https URI ?
Check your firewall and proxy (if so).
This command will produce a bunch of (mostly unhelpful) information, but may also contain some hints..openssl s_client -connect github.com:443
Also your OpenSSL version seems low (probably unlikely)
Apart from this I am lost - seems that we have to provide sample data again :(
Would this make a difference? - https://twitter.com/GitHubAPI/status/330044456986353668
(1) I tried the test code with an HTTPS target (https://duckduckgo.com) and it worked - so it is not an inherent error with HTTPS
(2) I rewrote the test code to pull the rate limit from github, and it returns the same unknown protocol error - code is shown in the email transcript below.
Given the tweet that Michael pointed to, I have emailed github support asking if the error is related to their recent change:
=== email begins ===
Hi,
Not sure if this is due to your recent change to libcurl for all HTTP-based hooks, but I am getting the following error:
Notice: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol in test.php on line 15
I created the test.php file to illustrate the error, the code follows...
<?php
$ch = curl_init("https://<my username>:<my password>@api.github.com/rate_limit");
$fp = fopen("result.txt", "w");
$arr = array('User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31', 'Content-Length: 576');
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_setopt($ch, CURLOPT_HEADER, TRUE);
curl_setopt($ch, CURLOPT_HTTPHEADER, $arr);
if( ! $result = curl_exec($ch))
{
trigger_error(curl_error($ch));
}
curl_close($ch);
fclose($fp);
?>
Do you know why I am seeing this error?
Have I done something silly to cause it?
Any advice is very welcome.
Regards,
Chris.
Chris Jones-Gill
KISS Web Design
Company number: 7486736
VAT Registration: 107800539
=== email ends ===
Feel free to repeat this test on your own systems, see if the error persists.
I will update when I get a reply.
Chris.
PS
using openssl s_client from the terminal and using port80 (non https) also gives the unknown protocol error. Could the code be using port 80? it should use port 443 (https default port).
openssl s_client -connect api.github.com:80
CONNECTED(00000003)
140735284318684:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:766:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 322 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
If you use
openssl s_client -connect api.github.com:443 -srpuser <your username> -srppass pass:<your password>
you still get an error, but not the same one
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance CA-3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.github.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
[deleted because its too big to show here]
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.github.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
---
No client certificate CA names sent
---
SSL handshake has read 3641 bytes and written 583 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: C5971EF215A014B286F05C8E978E73212425DDEF0F6ACA34C3292EE4F4C53443
Session-ID-ctx:
Master-Key: DE59C46209C8C274356B56223CEDF1AC6ABE441A871CF28A64FE7C466C2B50DBA1BB598CD3506020043C3DA0228CFBAF
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket:
0000 - 25 ce 2d 52 0b 67 79 a2-47 48 3f d1 27 19 95 90 %.-R.gy.GH?.'...
0010 - 44 cc 71 fa 78 60 3b 6b-a2 a5 82 8e 7c 54 26 10 D.q.x`;k....|T&.
0020 - 7a 24 13 5d 8d 45 dd 0d-0b 19 8c c2 9a 7f f7 1d z$.].E..........
0030 - 34 8b 3d ea ed c4 f2 0e-62 19 ca aa f3 6e 27 81 4.=.....b....n'.
0040 - a9 e3 ed 6e 96 2b 7d 95-f5 a0 1a 19 fe 96 b5 71 ...n.+}........q
0050 - 43 7f f2 1a 28 4e de 16-22 d8 54 53 b9 de 15 a5 C...(N..".TS....
0060 - 33 f6 98 93 22 64 1e 36-9f ec 66 99 05 52 5a ac 3..."d.6..f..RZ.
0070 - ff a5 04 ec a0 c1 0a 2f-77 07 00 88 44 be 25 74 ......./w...D.%t
0080 - 12 09 9f 01 b5 64 0f f4-0a c5 81 89 a5 c6 c2 a6 .....d..........
0090 - ca f3 3a 06 13 f0 a4 36-9f 51 07 c7 56 99 04 b2 ..:....6.Q..V...
Start Time: 1367608326
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=0
I tried changing the test to use port 443, but it didn't make any difference :-(
Chris.
The last output you posted seem correct, so I would guess that PHP is using the wrong port...
using plain cURL should work at least:curl https://[USER]:[PASS]@api.github.com/rate_limit
should give you 5000
Try alsocurl -v https://api.github.com
But let's hope the GitHub experts have some better answers ;)
Anyway.... Thanks a lot for your patience !
Ok guys, here is what I have done so far: Twigg and Mustache implmentation as a renderers. You can init them for example in the base View class. And then you can assign the data to the template. What do you think?
I think this looks pretty awesome (really) !
One tiny remark about code style: Could you name class members and methods without leading underscore ?
This has changed recently for private members. The current code style says the opposite for methods, but this is about to change (hopefully).
Hey, even I can understand what's going on there, and I don't even know much about these libraries!
Thus far, I'm liking everything I'm seeing in terms of rendering in here.
Thanks guys! @elkuku just done that.
Also I was able to register the "Text" class for using in Twigg templates. It was not so hard to do, just added it as a global variable. Then you can call it like this: {{ text._('COM_TRACKER_FILTER_STATUS') }}. So far so good :) The next step is to completely remake current Issues list template in Twigg manner.
After twitting a little with @dongilbert I decided to move registration of "Text" to AbstractTrackerHtmlView, because framework should be aware of any registration. Clients (Tracker in our case) should decide by themselves what to register as a global vars.
Great work there @b2z. As for what we were talking about previously with aliasing Text::_() to something else, I think using a custom defined function would work well: http://twig.sensiolabs.org/doc/advanced.html#functions
We would have something like:
$this->tmplEngine->addFunction(new Twig_SimpleFunction('translate', function ($string) {
return Text::_($string);
}));
My syntax might be off on that, maybe @fabpot could shed some light?
@dongilbert your snippet of code looks good to me and should work. If you need some help, don't hesitate. I'm not familiar with Joomla code, but I can help with the integration.
Ok, thanks Fabien. What we're trying to accomplish is the ability to have translatable strings. Currently, we use our Joomla\Language\Text::_() method to handle that. Translations are stored in INI files and loaded at runtime, and the Text::_() method finds the translation. So in usage, it would look like this:
use Joomla\Language\Text;
// template code
echo Text::_('STRING_TO_TRANSLATE');
We were able to get this integrated into Twig by assigning our Text class to a Twig global and then accessing it via {{ text._('STRING_TO_TRANSLATE') }}, but that syntax feels a little clunky to me, so we were looking for a way to possibly alias that method to another function, maybe translate('STRING_TO_TRANSLATE'). I've never created a custom Twig function before (and the doc page wasn't explicit), and I wasn't sure what all the args are when creating a Twig function. So, knowing that, does it still look like it should work?
Actually @b2z it might be so much simpler to add a new translate method to Joomla\Language\Text then we add text as a global to Twig and we get the simple and understandable {{ text.translate('SOME_STRING') }} method instead. I like that approach if others do. Then it's very clear what's going on. 
@b2z @dongilbert Here is a patch to make it work properly:
diff --git a/src/Joomla/Tracker/View/Renderer/Twig.php b/src/Joomla/Tracker/View/Renderer/Twig.php
index f2710d0..faf4192 100644
--- a/src/Joomla/Tracker/View/Renderer/Twig.php
+++ b/src/Joomla/Tracker/View/Renderer/Twig.php
@@ -52,9 +52,15 @@ class Twig extends \Twig_Environment
}
parent::__construct($this->twigLoader, $this->config['environment']);
+ }
+
+ public function getLexer()
+ {
+ if (null === $this->lexer) {
+ $this->lexer = new \Twig_Lexer($this, $this->config['delimiters']);
+ }
- // Set lexer.
- $this->setLexer(new \Twig_Lexer($this, $this->config['delimiters']));
+ return $this->lexer;
}
/**
@dongilbert Using text.translate() is indeed an option (where text is a global variable), but I can see to issues:
- it's going to be slower than using a filter or a function
- it's very verbose
For something that is going to be used a lot, I would recommend to create a dedicated filter or function. Actually, a filter is probably the best here:
$this->tmplEngine->addFunction(new \Twig_SimpleFilter('_', function ($string)
{
return Text::_($string);
}
which you can use like this in the templates:
{{ 'STRING_TO_TRANSLATE'|_ }}
And if you are supporting arguments:
$this->tmplEngine->addFunction(new \Twig_SimpleFilter('_', function ($string, $arguments = array())
{
return Text::_($string, $arguments);
}
{{ 'STRING_TO_TRANSLATE'|_({ key: value }) }}
@dongilbert I am with you to add 'translate' as a proxy to '_'. And I think we still will need all the Text object as a global, because other class methods also are useful.
@fabpot thank you! Will try it later after my working day is over :) If registering the Text object as a global is slow and the Text class has other useful methods (like sprintf) may be we need a custom Twig extension as a proxy for the Text class?
One of my favorite subjects...
I agree with @fabpot that text.translate is quite verbose.
I don't want to get too deep but... please let's just use J\Text::_() without any arguments.
Also: please don't use J\Text::sprintf() as this has been the cause of oh so many errors.
I hope we don't get tempted to use these (...) JavaScript supporting functions as they are really ugly (sry)
Last I can not resist to ask if somebody has thought already to get rid of those ugly ALL_CAPS_KEYS...
PHP has absolutely no issues with lower case letters and even spaces contained in ini file keys.
Maybe some day we get to some decent po files.
Apart of this: @b2z you rock :)
The alternative for me is plain sprintf() :P
echo Text::sprintf('MY_FANCY_KEY', $alpha, $beta, $gamma);
// vs.
echo sprintf(Text::_('MY_FANCY_KEY'), $alpha, $beta, $gamma);
Now what would be even better:
echo sprintf(Text::_('My %1$s has %2$d on their %3$s.'), $alpha, $beta, $gamma);
umm... can we use sprintf() and stuff in a Twig template ?
It's not my intention to overcomplicate things at this point. If you find a solution so we can make our app available in more than one language I will be more than happy ;)
I have not heard anything back from the github team regarding the 'unknown protocol' error.
I have been playing with AngularJS a bit more though.
Have a look at http://jissuesajs.unknown.org.uk/ajsissues
which is the basic list view (none of the filter are active, nor the search, they are there as placeholder for now)
Click issue 74 or 75 (they have comments) to see the single issue view
(I only have a limited data set of these 20 issues)
Screenshots for those who want them...
Issue list
single issue
Very impressive stuff there.
Can't tell you how awesome that looks!
[image: Small Logo] http://www.s-go.net/
Chad Windnagle
s-go Consulting
607-330-2574 x103
607-229-6260 (Cell)
Website Design - SEO - Video http://www.s-go.net/
Follow Me: [image: Facebook] http://www.facebook.com/sgoconsulting [image:
LinkedIn] http://www.linkedin.com/in/drmmr763 [image:
Twitter]http://www.twitter.com/drmmr763
On Wed, May 8, 2013 at 10:32 AM, Don Gilbert notifications@github.comwrote:
Very impressive stuff there.
—
Reply to this email directly or view it on GitHub#86 (comment)
.
We're definitely going in the right direction with this :)
@KISS-Web-Design nice :) As I understand you are using the same, but modified default.php from the /tmpl folder of the view?
Hello Joomla! @KISS-Web-Design would like to introduce you to today's leading edge front-end web development technology! =D
Change topic to language: I've been asking the same questions on language/translation. Last night, I started looking at anonymous functions for translations. I am considering that approach, maybe it's also applicable here? https://gist.github.com/AmyStephen/5538748
I think JText is good as is. It can be expanded on to allow for other
formats than .ini, but overall it's pretty decent code.
I've been thinking about your approach Amy, and I can't say that I love it.
But, then again, this is coming from a guy that is not to worried about
translations, nor do I implement them very often. So, others for sure have
more qualified opinions than mine.
On Wed, May 8, 2013 at 11:05 AM, AmyStephen notifications@github.comwrote:
Change topic to language: I've been asking the same questions on
language/translation. Last night, I started looking at anonymous functions
for translations. I am considering that approach, maybe it's also
applicable here? https://gist.github.com/AmyStephen/5538748—
Reply to this email directly or view it on GitHub#86 (comment)
.
I like JText as is personally, but am always welcoming ideas and improvements. That said, one area this project makes its money will be translations. It would massively improve the user experience if we can have an interface in the user's language (if translations are available). So we have a mix of running efficient code and allowing translators (Joomla's Translation Teams, OpenTranslators, or whoever) the ability to actually translate in an efficient manner.
@dongilbert It's not about translations -- it would be assumed you would use the approach with JText in Joomla. The example is one that shows how to do so without introducing coupling by injecting your dependencies as an anonymous function that could then be easily changed if another translation approach was required.
What I personally want is:
- Readable code ("plain strings" instead of keys - still being unique)
- Maintainable code (I don't want to touch language files or hunt for missing keys) This must be automated.
- Good JavaScrpt support (which will become more important in the future and is painful ATM)
I want to write my code without worrying about keys and pressing shift lock.. then I want to "push a button" so my language files are created (or updated), push another "button" to upload my files to transifex (example) or use a nice offline tool (like PoEdit), yet another "button" to download the new translation from transifex and incorporate them into my code base, push the changes and... release ;)
That said: JText really sucks from the view of a coder and translator.
I'll agree there's (a lot of) room for improvement. It is mildly annoying to go to a layout and see a bunch of language keys that, unless you're the developer or have the language file. But, I do like that it is relatively easy for me as a developer to drop a bunch of language keys and appropriate translations in a file that doesn't require any additional software and call it a day.
FWIW, I've got a half-written wrapper to the Transifex API (haven't touched it in a year) built JGithub style if such a library doesn't exist elsewhere or anyone feels like doing something with it. Maybe this year I'll finish it too.
@elkuku totally agree. Seems like in 1.5, we used the English language string as the translation key. Not sure why we moved away from that. It's about as good as it gets. I'm using that approach with Molajo.
I have a database adapter (plans for other adapters) and an automated process for identifying strings to translate. The process adds them to the database for each supported language. It's currently set up for admin only.
Also, each language string is simply a piece of content, just like an article or comment, for example, meaning it has a URL. Have not created an interface for it, yet, but the idea is that the URL will be used for an HTML5 in place editing.)
Mainly, the class is very simple. There's really not that much going on but Oh. My. God. all those classes and methods in various places for Joomla are horrifying, the system has sort of outgrown itself.
There are things I do not have like pluralization, and nothing for JS translations, but a solid, simple start, I think. If any of that is helpful, just ask. Anything you guys want to use in Molajo is available to you. We can rebrand, no problem.
Seems like in 1.5, we used the English language string as the translation key. Not sure why we moved away from that.
That was done to avoid "duplicated keys" so every key was prefixed with something like JGLOBAL or COM_FOOBAR.
While this solves the problem, it makes the code AND the language files quite unreadable.
Worst case: The language files won't load or (which is really a pain for 3pds) missing translations, so the keys are displayed to the end user causing lot's of confusion and distorted layouts.
Since we got now the whole thingy at our hands, maybe we can make our app so smart to automagically add those prefixes (as a first step) ?
@b2z - yes, I modified the original default.php to act as an api endpoint. It simply creates a json object from the original incoming data, which is then 'echo' d - so the raw data can be seen by going to the default web page.
The view I added uses 'GET' to retrieve this json object and then process it into a list, the single issue view is still the same base data - but I use the issue number to 'GET' the comments directly from github using its api, again as a json object (which includes the url for the avatars, link backs for the user and the issue.)
Once the data is received the routing (just 2 views at the moment) and data processing all happens within AngularJS.
@dongilbert @davidhurley @drmmr763 @AmyStephen thanks for the kind words, glad you like it so far.
@KISS-Web-Design thanks for the explanation. Is the full code of it is on the GitHub? As far as I can see it is not, but I would like to explore how it is implemented ;)
@b2z I have pushed the recent changes to my jissues fork
https://github.com/KISS-Web-Design/jissues
Explore away :-)
@KISS-Web-Design thank you :) I am also googled a little bit about angular.js and still do not exactly understand, what it is the role of PHP in this - just to generate some JSON data sets (provide RESTful data sources)?
BTW it is MIT licensed :(
We can use MIT licensed software in a GPL application. That's about my extent of knowledge on that topic though. The file upload plugin we're looking at using is MIT licensed also.
Always good to remember Joomla's GPL license does not come into play for anything but PHP code. (Meaning it has no impact on JS, CSS, images, and so on.) That's not to say you can't use non-GPL code with Joomla, MIT is compatible. But the Joomla GPL license never has an impact on anything that's not PHP.
@b2z you're welcome.
Yes, you are correct - the PHP code provides the raw data, in JSON form, and the template renders it. So, yeah, I treat it like a RESTful data source.
But I see the PHP code being much more than that, there are a whole host of actions that have to happen in the backend - database comms, pulling data from other sources (github), accepting inputs and sanitizing it from the front-end template (for comments / notes / whatever).
What I have pulled from github is only what you can already see on github, just formatted differently. This application must do more than that, it has to add something valuable that is not (currently) available within github.
I have not read any requirement specification (I suppose I should really, my bad), so I don't know what exactly will be added, or how much of the data within github will be replicated, and how much of the github data will be accessed 'on demand' (using the end-users' authenticated session to provide permissions). I'm guessing that an ideas database, extending the 'label' functionality of github, and other loop-closing functionality - idea to feature-request to pull-request (with test code) to merge to commit and back to close the idea as 'implemented'. Maybe to become a single-point of reference for all development discussions - able to pull (relevant) data in from google groups, google docs, etc.
My thoughts are that the data storage, processing and any 'heavy lifting' will be done in the back-end using PHP. A simple interface between the template and the back-end will provide a JSON object based on what the template requests (be that a list of open issues, pull requests, events, etc - or even just the github references). The template makes it all pretty and provides a number of views for the end user to navigate around - either using the data from the back-end, or pulling the details direct from github on demand (based on the github reference from the back-end).
So there are 2 sides to the application - one, php+database, doing the backend stuff, the other, AngularJS+HTML+CSS, dealing with the front-end, allowing the end user to manipulate the way they view the data without causing any extra loading on the server (cpu cycles, memory, bandwidth).
Thats not to say that other, php-based, template solutions can't be used at the same time - there may be views that are more suited to using a server-side template solution, and those views should use the most suitable solution and not dogmatically adhere to only one (providing doing that doesn't make the application overly complicated of course).
As for the MIT licence, as @mbabker and @AmyStephen have pointed out, as it is not PHP code the Joomla GPL licence has no effect - and as the MIT licence is GPL compatible, it is not a big departure from the GPL in any case.
Hope all that makes sense, it's getting late here (midnight) and I need to stop working or I will be up all night ;-)
In terms of intent, essentially we want most of the data already available in the Joomlacode tracker. Some of that exists in GitHub (dates, title, description, etc.) but a lot of other things (categorization, item status, priority, tech data, etc.) aren't present and will be added to our application. Basically, if you see it on Joomlacode (mostly replicated on the older test instance at http://tracker.babdev.com), it needs to be in our interface.
The idea is that a new report on GitHub will automatically add a tracker item in the application. Users won't be requesting data from GitHub each time the page is requested; they'll pull from our database. All the GitHub interaction will be at a level the user shouldn't have to touch when all is said and done (new GitHub items open reports on tracker app, commits close items on tracker app, comments on tracker app feed into GitHub issue). And that's just the basic stuff off the top of my head. The roadmap shows this thing growing into *THE* centralized code collaboration hub for Joomla as it gets built out.
As @KISS-Web-Design somewhat puts it, the server side of the application will be (mostly) familiar Joomla code. All the heavy lifting is done in ways we've been doing it for years, just brought into modern times and decoupled from some system limitations and issues the CMS can have. The client side is reaching into uncharted territory; without doing some heavy lifting of your own, you've never had the option to easily integrate with rendering engines/frameworks/whatever-they-may-be. To borrow a famous line, we're boldly taking Joomla code places we've never seen it taken before.
And that's what's exciting about this issue as a whole, the various discussions about technical details that we wouldn't be able to discuss if we were using the CMS, or even the Platform repo (as the older version of the code shows). Who here can get Twig or AngularJS running in the CMS without completely hacking the higher level of the system code (namely the view classes and JDocument); I know I'd rather not try. As #103 shows, we have the chance to bring in outside code without hacking our system to make it work. I don't know a thing about Symfony's code, but there's a suggestion to use its Session system in the Framework and drop our home grown Session package, and its implemented in the PR @elkuku submitted. Do that in the CMS and see how much havoc you bring about.
Anywho, back to the root of this issue, the rendering code. There's actually a reason I haven't flat out said "we're using X engine, make it work". In part, as I've said before, because I'm not a front end guy and would rather not make that decision on my own. In part, I really like where both models are going (and the PHP renderer stuff has a lot of value to the Framework even if not used here). And in part, I'm getting to learn about other solutions along the way and seeing how those work in our code base can really help me understand those types of things. With that said, I wouldn't go about working with more than the two functional views at the moment since a lot of code is yet to be converted and I don't want to see someone's time totally wasted.
This code base, and especially a lot of the topics that have come up since starting to build from the Framework, have brought a lightning bolt of energy to quite a few folks in the Joomla community, myself being one of them. I'm excited to see what we can write (and I'm kind of looking forward to the day we get to hang a "closed for business" sign on the CMS' use of Joomlacode 
).
@KISS-Web-Design thank you for explanation :)
Yesterday I pushed complete Twig example to my twig branch. Let me recall what was done:
1. View and Renderers. Renderers potentially will go up to the JFramework.
2. Templating.
Currently there is only Issues list example, but you should get the idea. Sad I do not have a live site up and running, but I will later today or tomorrow. Basically everything looks exactly the same way as on Michael's tracker example.
P.S.
Oops, just realized that forgot to push /js and /css dirs to twig template 
So if anyone wants to see it action on your local copy you should move bootstrap.min.js to /js, template.css from here and bootstrap.min.css to /css.
@mbabker Thanks for the clarification, it's really useful. +1000 for 'bye-bye Joomlacode'
I like the work being done on the PHP renderer, and see that as great addition to the core framework - so useful to be able select the rendering engine per project (or view) - Twigg, Mustache (I will see if I can add AngularJS too), perhaps others will want other engines in future and can submit PR's.
I am learning such a lot about AngularJS too, it is one thing to play with a language (sample apps, hello world!, todo, etc) but another to try and do something new. So even if the end result is not AngularJS, I think my time has not been wasted at all - no learning experience is a waste of my time :-)
Ok, I have updated my twig branch and all files are in place now 
And I have a live example of Issues list up and running, at last... 
Added an 'events' tab to the single issue view, it shows things like who referenced it, a commit id (linked to github) if one exists for that event, and who mentioned and/or subscribed to that issue. It all comes from github, using their API.
http://jissuesajs.unknown.org.uk/ajsissues#/issuelist
Issue 3 has plenty of comments and events if you want to see the results.
My repo has been updated to reflect the live site.
@AmyStephen back online, I think. Server was working, but seems it was DNS problems.
@KISS-Web-Design gj ;)
So may be it is time to make a decision what implementation to choose: Renderer or AngularJS? As Michael said:
a lot of code is yet to be converted and I don't want to see someone's time totally wasted.
I vote renderer because it's needed in the Framework as a whole.
—
Sent from Mailbox for iPhone
On Sat, May 11, 2013 at 1:25 PM, Dmitry Rekun notifications@github.com
wrote:
So may be it is time to make a decision what implementation to choose: Renderer or AngularJS? As Michael said:
a lot of code is yet to be converted and I don't want to see someone's time totally wasted.
Reply to this email directly or view it on GitHub:
#86 (comment)
If I was to do it this moment, I'd say the Twig version because it's using the local resources like the desired end state is while the AngularJS stuff is pulling direct from GitHub right now (which isn't necessarily a bad thing, but we'd be fighting with API rate limiting).
Michael - AngularJS can work with PHP data, see this comment of @KISS-Web-Design.
Don - renderer is in my repo, it will not go away ;)
I would go for Twig, because it seems easier to me to adapt existing code (that could be wrong due to my lack of JavaScrpt knowledge...)
While I really love the overall rendering speed improvements, an AJAX based solution would offer. Really glad I learned something about it here, even if we don't go with it - thanks @KISS-Web-Design for that.
That's why I said if I were to vote right now. I know it can, I just also
know Chris went about it differently to get a working POC going.
On Saturday, May 11, 2013, Dmitry Rekun wrote:
Michael - AngularJS can work with PHP data, see this comment#86 (comment)of
@KISS-Web-Design https://github.com/KISS-Web-Design.Don - renderer is in my repo, it will not go away ;)
—
Reply to this email directly or view it on GitHub#86 (comment)
.
Hi,
In my live poc, the list view is from the framework (joomla) database, as is the details table in the single issue view. The comments and events are the data I pulled from github, using unauthenticated connection - so there are data limits, but the data is cached locally so there is only one data-pull per user session to minimise this (and for speed, and good practice).
I plan on loading the joomla/framework database with all the github data for a limited dataset, and then not using any of the data from github.
I also like the renderer code, and am looking at adding the code for an AngularJS option. So the template choice (using twigg, mustache or angular) is all done through the same server-side route. This should make it easy to switch temptating choice, maybe with a configuration option, and make direct comparisons really easy (same server, same data source, etc).
Let's keep working together, and separately, to get the best solution for the application. This means 'the best solution for' current developers, future developers, maintainers, contributers (to the jIssues codebase) and last but not least (probably most importantly) the people who will use it everyday.
I'm really enjoying this process, and am learning stuff all the time - about the framework, the jissues application, the github api, AngularJS, json data processing, the list goes on! None of which will be wasted, be it here or on other Joomla projects.
Chris.
I really appreciate the positive attitudes in this thread. It's a refreshing change from what goes on in the mailing lists. Thanks to everyone involved.
—
Sent from Mailbox for iPhone
On Sat, May 11, 2013 at 5:53 PM, Chris Jones-Gill
notifications@github.com wrote:
Hi,
In my live poc, the list view is from the framework (joomla) database, as is the details table in the single issue view. The comments and events are the data I pulled from github, using unauthenticated connection - so there are data limits, but the data is cached locally so there is only one data-pull per user session to minimise this (and for speed, and good practice).
I plan on loading the joomla/framework database with all the github data for a limited dataset, and then not using any of the data from github.
I also like the renderer code, and am looking at adding the code for an AngularJS option. So the template choice (using twigg, mustache or angular) is all done through the same server-side route. This should make it easy to switch temptating choice, maybe with a configuration option, and make direct comparisons really easy (same server, same data source, etc).
Let's keep working together, and separately, to get the best solution for the application. This means 'the best solution for' current developers, future developers, maintainers, contributers (to the jIssues codebase) and last but not least (probably most importantly) the people who will use it everyday.
I'm really enjoying this process, and am learning stuff all the time - about the framework, the jissues application, the github api, AngularJS, json data processing, the list goes on! None of which will be wasted, be it here or on other Joomla projects.Chris.
Reply to this email directly or view it on GitHub:
#86 (comment)
Ok, Michael, I will ;) I just want to polish some things and redesign renderer a little bit according to this discussion.
And as I understand we can move index.php and .htaccess to base directory then?
There should be a symlinked index.php and .htaccess in the base directory pointing to those in the www directory. This might not work well in some environments, but I'm trying to keep the repo as close to how the file structure on the server I'm pushing code to is. I did the symlink as a convenience item basically (and it works on my MacBook), but if it causes issues, we can look at making a copy of those files at root.
Ah, ok then. I am using Windows and have had some problems with it, but found a RewriteRule to run my local instance properly. May be I need to add it to readme for those who are running Windows?
That could be helpful. Of all the code I've worked on using GitHub, this repo is the only one to not have a commit from my Windows box, so I wouldn't have thought of that. 
IMHO we should remove the symlinks from the root.
Personally I have no problems using either the root or the www directory, but this is a security risk that we should discourage ;)
There are myriads of ways to a "proper" setup - a vhost pointing to the correct directory being the best :P
No issues here with dropping them if it appeases the crowd. Like I said, it was more of a convenience thing; I'd rather type http://localhost/jissues instead of http://localhost/jissues/www. And I also know not to upload said symlinks up to the server I've got the new code on.
When we will move to the renderer /www folder will be needed just for template files (if we will not choose another name for them, like /templates for example).
The templates themselves don't need to be publicly accessible, just the
assets of the templates, right?
That would make sense to me.
We could put the index.twig file somewhere in the www folder, because template guys might expect it here... (having it publicly accessible should not harm).
We could place the "components" output where the "old" PHP templates used to be.
If we decide to create some reusable blocks, those might go under /src/Joomla/Tracker/SOMETHING
making sense ¿?
Guys what is the reason to hide templates and do not make them publicly accessible?
For me the beauty of templates is one common central place. Remember, we are making a standalone application, not the CMS. We will not have any overriding or something (or we do?). So I do not see any reason to break them into separate places like the "components" output. Instead of that just store them, for example, under the templates folder. Then we could have any structure we want. For example:
- /templates/viewName.layoutName;
or if we will have crossing view names
- /templates/componentName/viewName.layoutName
That's the point - one central place for the output. Simple approach:/templates/index.twig (main tpl)
/templates/issues.index.twig (extends index.twig)
/templates/issues.list.twig (extends issues.index.twig)
/templates/user.index.twig (extends index.twig)
Using components:/templates/tracker/issues.index.twig (extends index.twig)
/templates/tracker/issue.index.twig (extends index.twig)
/templates/tracker/issue.comments.twig (extends issues.index.twig)
/templates/user/users.index.twig (extends index.twig)
One more problem we should deal is - how we will output the raw data (like AJAX returns)? Since we are rely on a renderer we can not simply echo the data in the controller. So should we invoke a view and then render the output or we should directly invoke a renderer in the controller? If second then we should make our renderer available in the controller.
Centralize them, yes. You won't regret it.
On Tue, May 14, 2013 at 1:18 AM, Dmitry Rekun notifications@github.comwrote:
Guys what is the reason to hide templates and do not make them publicly
accessible?For me the beauty of templates is one common central place. Remember, we
are making a standalone application, not the CMS. We will not have any
overriding or something (or we do?). So I do not see any reason to break
them into separate places like the "components" output. Instead of that
just store them, for example, under the templates folder. Then we could
have any structure we want. For example:
- /templates/viewName.layoutName or if we will have crossing view names:
- /templates/componentName/viewName.layoutName
That's the point - one central place for the output. Simple approach:
/templates/index.twig (main tpl)
/templates/issues.index.twig (extends index.twig)
/templates/issues.list.twig (extends issues.index.twig)
/templates/user.index.twig (extends index.twig)Using components:
/templates/tracker/issues.index.twig (extends index.twig)
/templates/tracker/issue.index.twig (extends index.twig)
/templates/tracker/issue.comments.twig (extends issues.index.twig)
/templates/user/users.index.twig (extends index.twig)One more problem we should deal is - how we will output the raw data (like
AJAX returns)? Since we are rely on a renderer we can not simply echo the
data in the controller. So should we invoke a view and then render the
output or we should directly invoke a renderer in the controller?—
Reply to this email directly or view it on GitHub#86 (comment)
.
Guys what is the reason to hide templates and do not make them publicly accessible?
Not sure if we have a misunderstanding, but "publicly" means that the Twig templates don't need to bee accessible with the browser - no need to put them in www ;)
Seems that you have thought a lot more than I about the topic so, please scratch my previous comment, go with the centralized approach (I would vote for /template/*), and open the PR ;)
Could you elaborate - what is the purpose of www ? It's like media in the CMS?
I would vote for templates or themes. Thinking into the future we could have different themes 
, so we could put our current work into the /templates/default/* for example. Am I correctly understand that these folders should be under the root?
/www is the folder that has all the web accessible code; same as /public_html, /www/, or whatever else on your live server. My intent here is to keep that code down to a bare minimum, so that would be the index.php, .htaccess, and media (CSS, JS). Everything that has no need to be accessible via a URL can go under the root of the repo.
As for /template versus /templates or /themes, I have no preference honestly.
Still confused... Under the public_html we usually have all the code (including sources). And currently JPATH_BASE is bound to the root (same directory where index.php resides). Do you mean that to run our app we should put index.php, .htacces, media staff under the public_html and non-public staff somewhere else? Can you show an example of structure how it could be on the hosting?
That is the typical usage, but the new paradigm in the PHP world is you
don't need to make all your code accessible from the web. Right now in
Joomla CMS, all the libraries/joomla/*.php files have
defined('JPATH_PLATFORM') or die; in them. This is because you can type in
the location of the file in the browser and access it.
joomla.org/libraries/joomla/factory.php
The new paradigm is, you don't ever need those files to be web-accessible.
So, as Michael stated, the "web-root' becomes the /www/ folder and it
contains only the index.php, an htaccess file, and then assets that need to
be loaded by the end user. Template code and vendor libraries are all
parsed and used behind the scenes, never access directly at a url, as
opposed to images and css.
On Wed, May 15, 2013 at 10:03 AM, Dmitry Rekun notifications@github.comwrote:
Still confused... Under the public_html we usually have all the code
(including sources). And currently JPATH_BASE is bound to the root (same
directory where index.php resides). Do you mean that to run our app we
should put index.php, .htacces, media staff under the public_html and
non-public staff somewhere else? Can you show an example of structure how
it could be on the hosting?—
Reply to this email directly or view it on GitHub#86 (comment)
.
Don worded it much better than I. Even I was getting confused by the response I was typing.
Actually JPATH_BASE is one directory above the www/index.php ;)
Thank you Don, almost got it now :) Correct me if I am wrong, in such case we should change JPATH_BASE to point one dir up?
Oops sry. It is. Well everything is clear for me now. So I will go to prepare a PR then. Hope to make today :)
Since everyone seems to best get notifications here, if you've contributed any commits to the repo, claim it on Ohloh - https://www.ohloh.net/p/joomla-issue-tracker
Closed. All discussions regarding JTracker project now are happening in the G+ community
-
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)