File/Class Structure for "Components"

[mbabker]

The Platform version of the application reused the tried and true method of components as they're known in the CMS. Obviously, that goes out the window with the reboot. So, we have to figure out how to handle what we've been using as components. Some points to consider:

• The routing system needs to be able to find the code
  -- If we use the Framework Router, the components will have to share a common prefix, so they'll be in a common namespace. I'm thinking they'll be in the Joomla\Tracker\ namespace but I'm not sure what to call them. Components, Services, Apps?
• Site/Admin applications
  -- The CMS has its two applications. Aside from highly customizing com_categories, there really hasn't been an admin application built for the tracker. Do we leave it this way, or do we develop it? This further complicates the file structure a bit as we'd have to consider the namespacing so we don't get conflicting class names as the entire file/class structure will be in the autoloader.

[realityking]

IMO a tracker doesn't need a separate admin application. The couple of views you wouldn't need regular users to access can be easily integrated into the main app.

[mbabker]

I've been leaning towards the single app approach (we only touched admin to manage some fields, well, that's all that's been developed so far). Thought I'd throw that point out there just to validate thinking. So, just need one application and ensure that our ACL system can handle ensuring users don't get to places we don't want them to be. That part's answered.

So, back to the structuring part. I still don't know what to call these things other than components (it sticks with me, guess it's a Joomla thing). I'm tempted to just end this debate and put that code in the Joomla\Tracker\Components namespace and move on to building the router.

[b2z]

Imo it is not a key thing to debate much. "Apps" inside App will confuse. "Services" are good, but there could be a confusion with the Web Services? If we consider that these will be implemented in Web Services manner, then I would stick with "Services". Otherwise "Components" would be the best name.

[mbabker]

Components it is then.