[#117] - Folder revision proposal
- Closed
- 14 Jun 2013
- Medium
- Build: master
- # 117
Step 1 (short term / now)
I have a suggestion for the folder structure though (one I use at work). This is to move the /Joomla/Tracker folder up one level to /src/Tracker, and then use the /src/Joomla folder to store code that could/should/maybe be contributed back to the Framework.
What that means is you put all the tracker specific code in the /src/Tracker folder, and then the Tracker has "packages" beneath it (the Tracker can sort of be considered as a top-level "vendor" of sorts).
Considering the Renderer package as an example, you can put that under /src/Joomla/Render and just let it "bake", pushing it upstream to the Framework when it it tested and fully documented.
Something like this:
/src
/Joomla
/Renderer
/Tracker
/Application
and so on.
Step 2 (medium term)
Further to this, and this is more thinking out loud at the moment, I had the though of instead of "component", we could use the notion of Tracker "Apps". In folder terms, it could be something like this:
/src
/Joomla
/Renderer
/Tracker
/Application
/TrackerApps
/Groups
/Issues
/Projects
/Config
/Stats
/Debug
/Users
Where the notion of an "app" is covers anything from what we know as a component, module or plugin in Joomla speak. The "Tracker" [vendor] is the core application and you could define a heap of base/abstract classes, interfaces and traits. For example class ProjectsModel extends \Tracker\Apps\AbstractModel (again, just thinking out loud conceptually). The idea here is that we can very easily add more functionality in discrete blobs but keeping the namespacing clean and separate. I think it also sets a good stage for testing how the future CMS family of applications might/could/should work.
Step 3 (long term)
In terms of how each "App" is set up, I'm still giving that a bit of thought because I my current work is around backend code driven by web service end-points. But I am leaning towards the idea of a routing
Thoughts?
I think what Andrew's suggesting is that we basically have 2 top level namespaces for the tracker application. namespace \JTracker; would be all of our library level code and namespace \JTrackerApps; would be what we have now under namespace \Joomla\Tracker\Components;. That actually feels like a pretty clean setup and separates the code better.
I also like his idea for leaving namespace \Joomla; for stuff we build that would best be pushed up to the Framework. It lets us build the code and provision it following the same namespacing as what it would be in the Framework, then when it is accepted, we just update our Composer references and remove the code from our /src tree, no code changes necessary (whereas now with the renderers, we'll have to change a few use statements to reflect the right FQCN when moved).
Hmm, but I thought that the idea of Andrew was to rename folder structure along with the namespaces. We need Andrew here to elaborate :)
The way PSR-0 works, the namespace follows the folder path. Notice how
\Joomla\Tracker\Application\TrackerApplication is at
/src/Joomla/Tracker/Application/TrackerApplication.php
On Tuesday, June 4, 2013, Dmitry Rekun wrote:
Hmm, but I thought that the idea of Andrew was to rename folder structure
along with the namespaces. We need Andrew here to elaborate :)—
Reply to this email directly or view it on GitHub#117 (comment)
.
As for 1) - I'm all in.
I think that's a confusing thingy right now and an additional layer separating "our" stuff from what could/should belong to the core framework would make things much clearer.
As a Joomla! fan I would also follow @mbabker and @b2z in not loosing completely our JUmbrella.
Let it be /src/JTracker :)
As for 2) - I also agree that it makes sense to move our "component thingies" one level up and it makes even more sense to make them do "more" than a CMS component is currently capable of.
As for the naming.... that discussion could be endless... while I see the need to have it resolved at some point...
I would find App rather confusing, as we already have an Application.
Do we need to invent something new or can we live with the fact that we are still using Joomla! and are just reinventing its functionality, preserving some old and familiar names ?
If we really need something "fresh", I would go for Complement.
As for 3) - I think that's where we are right now.
What the framework offers us ATM, in terms of MVC and other "stuff" needed to build a web application, is a good solid base where we can build on.
We decided to go down the road of single action controllers and use the provided routing system.
While I'm getting warm with the idea and functionality, I would really like to change the file- and class names of our concrete routers (and the rest of our MVC implementations in our "Components") and loose the postfix, e.g. instead of SaveController just Save. I think that would make things easier.
What we currently use as our item and list models is something adapted from the CMS - still somewhat expecting some JForm processing..
Oh JForm... let me confess that I am really missing it ;) knowing the flaws it has (large forms... XML not really the best option, etc) I like how its build and we really need "something" capable of handling client and server side validation.
Maybe we can refactor JForm to use YAML files and tell it to use some fancy JS client side validation with bootstrap styles and stuff.
We might also think about "something" new to build custom fields, now that my little idea using com_categories is obsolete ;)
I am really glad to have @eddieajau on board. I would really love some experienced programmer to have a look at what I've hacked together so far - just to prevent a major security breach or something similar... Welcome :)
OH: Before the big renaming party begins... please let's first merge the currently active branches ;)
Michael's summary and assumptions is on the money. As for the name of the container for "extended features that are not part of the bootstrapping app", I'm open to suggestions. While I know that JTracker is technically an application, a user doesn't think of it as an application, they think of it as a website. If you consider a smart phone, the JTracker site is the device and the "apps" are what you install to get extra features. Long term, if JTracker forms the basis of Joomla CMS 4, to the user you are installing "apps" in your CMS (rather than components, modules and plugins).
At the end of the day though, I don't really care what "they" are called, but I think it's worth separating the JTracker "core" code from what we know today as components, modules and plugins. So, you can install an "app" (or other name when someone has a lightbulb moment), a language (pack) or a theme (a template + overrides).
As for JForm, what I've done at work is bust up the Filter package into discrete filters, and added a Validation package. Each data object (more or less similar to JTable) would filter each property as it is set (so, $table->id would call a Non-zero, Unsigned, Integer filter to set the value), and you'd have a validate method (in the JTable-like class) that would return a boolean and an array of exceptions. In other words, what JForm does in XML, I'm binding directing into a data object. Now, that's web-services centric but the idea is that you could call a web-service to get the validation rules for a "form" and you'd translate that into Javascript.
Anyway, that's another sorry an one better told on a voice call (and on that note, if we could arrange "calls" somehow every two weeks or so to just sync up, that could be really cool).
Yep, I agree completely. Starting to create the idea of "apps" instead of a typical CMS setup with components, modules, and plugins is what we need to focus on. Looking 4ward ( get it? ) :) I think it's very important to focus on what we want to do next with a greater vision in terms of our installer.
Perhaps we need to setup a Skype chat unique for this tracker and then get on some bi-weekly calls. That'd be awesome. If everyone is ok with it I'll get one setup and we can start chatting a bit more live.
David Hurley
Joomla! CDM
On June 4, 2013 at 9:10:18 PM, Andrew Eddie (notifications@github.com) wrote:
Michael's summary and assumptions is on the money. As for the name of the container for "extended features that are not part of the bootstrapping app", I'm open to suggestions. While I know that JTracker is technically an application, a user doesn't think of it as an application, they think of it as a website. If you consider a smart phone, the JTracker site is the device and the "apps" are what you install to get extra features. Long term, if JTracker forms the basis of Joomla CMS 4, to the user you are installing "apps" in your CMS (rather than components, modules and plugins).
At the end of the day though, I don't really care what "they" are called, but I think it's worth separating the JTracker "core" code from what we know today as components, modules and plugins. So, you can install an "app" (or other name when someone has a lightbulb moment), a language (pack) or a theme (a template + overrides).
As for JForm, what I've done at work is bust up the Filter package into discrete filters, and added a Validation package. Each data object (more or less similar to JTable) would filter each property as it is set (so, $table->id would call a Non-zero, Unsigned, Integer filter to set the value), and you'd have a validate method (in the JTable-like class) that would return a boolean and an array of exceptions. In other words, what JForm does in XML, I'm binding directing into a data object. Now, that's web-services centric but the idea is that you could call a web-service to get the validation rules for a "form" and you'd translate that into Javascript.
Anyway, that's another sorry an one better told on a voice call (and on that note, if we could arrange "calls" somehow every two weeks or so to just sync up, that could be really cool).
—
Reply to this email directly or view it on GitHub.
Aww, man... I've been doing good keeping this project out of the Skype world 
Definitely do need to look at bringing everyone together and talking though. That would benefit all.
Hahaha! Yeah I had a feeling ;)
Thanks,
David Hurley
Joomla! Community Development Manager
On Tue, Jun 4, 2013 at 9:38 PM, Michael Babker notifications@github.comwrote:
Aww, man... I've been doing good keeping this project out of the Skype
world [image:Definitely do need to look at bringing everyone together and talking
though. That would benefit all.—
Reply to this email directly or view it on GitHub#117 (comment)
.
If we had, say, a Google hangout once or twice a month, and recorded it, that would probably do. If we can avoid the endless Skype chat for as long as possible (forever is preferable), that would be ideal.
I like that idea. Let's do something different and new. Google Hangout would be a refreshing change.
David Hurley
On June 4, 2013 at 10:09:44 PM, Andrew Eddie (notifications@github.com) wrote:
If we had, say, a Google hangout once or twice a month, and recorded it, that would probably do. If we can avoid the endless Skype chat for as long as possible (forever is preferable), that would be ideal.
—
Reply to this email directly or view it on GitHub.
Actually, going a bit off topic but if we had a G+ community, that could replace the mailing list and you can link media, hangouts, etc to it. ??
Compare: https://plus.google.com/communities/103500906097842801714
I'd actually have a reason to log into G+ more than once a blue moon then!
So, let's give this a shot: https://plus.google.com/communities/102541713885101375024
(On a side note, I could really use a 250x250 version of either the Joomla logo or the graphic being used on the developer site :-) )
I'll get you the logo. :)
David
On June 4, 2013 at 10:40:42 PM, Michael Babker (notifications@github.com) wrote:
So, let's give this a shot: https://plus.google.com/communities/102541713885101375024
(On a side note, I could really use a 250x250 version of either the Joomla logo or the graphic being used on the developer site :-) )
—
Reply to this email directly or view it on GitHub.
I need to install what to make those google hangout thingies happen on my penguin computer ??
Actually since Microsoft has released the latest Skype version with increased security if you log in with your Microsoft account, I try to avoid Skype since I like security ;)
Now the google guys.....
I really love the simplicity of IRC ;(
But yes, I strongly believe that it would be very cool to have some "instant communications" regarding the future of the tracker project, so I'll install this RPM and see if we can come together.
For the Hangout stuff, looks like this page will give you everything you need - http://www.google.com/+/learnmore/hangouts/
Trying out the philosophical side-discussion for what to call installable "thingies" here:
https://plus.google.com/communities/102541713885101375024/stream/9ba0eb01-12df-48d8-9645-679c7cc326b0
So I decided to start this renaming party to see how those Apps may feel...
Open for suggestions: https://github.com/joomla/jissues/tree/renaming-party/src
One remark: Things like "Projects", "Groups" and ACL related stuff are somewhat coupled to the tracker, and I feel if we separate them to gain another level of customization, we would add at least two levels of complexity - not sure...
Please scratch my last remark... I created seperate Apps for Projects, Groups and other stuff and it looks pretty cool :)
I love it!
That's looks really good. We should stick with it :)
P.S.
So many changes that I can't start to contribute again ^^ Everything is getting old in a few days :fastforward:
Oh come on, you can't be serous :(
I admit that there is a lot of movement right now, remember we are just building the "base". Once we have a structure we all agree on, the code should stabilize somehow ;)
Do you get merge conflicts ? Before using PhpStorm, I used meld which is multiplatform and does a fairly good job.
PhpStorm's diff and merge engine is outstanding and does an excellent job on merge conflicts ;)
Oh come on, you can't be serous :(
Of course I am not :) I am a little bit busy with the other staff now, but will be back ASAP ;)
Phew... please don't make me suffer
-
Makes sense to me. As it is now, our folder structure is starting to run kinda deep for no reason other than starting Components three levels down. I'd namespace Tracker at least as JTracker just in case.