Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers
__________________________
Gary Glass
On Feb 19, 2012, at 18:37, Andrew Eddie <mamb...@gmail.com> wrote:
> Not really much more to add. It's certainly on the radar and will
> take time as we continue to ween the Platform off the CMS. It's
> something I'm keen to see rationalised.
>
> Regards,
> Andrew Eddie
> http://learn.theartofjoomla.com - training videos for Joomla developers
>
>
>
> On 19 February 2012 06:43, Louis Landry <louis...@gmail.com> wrote:
>> The short answer from my end Jeremy is that yes, this is on my radar at
>> least. I know that Ian, Andrew, Rob, Sam and I have all discussed it at
>> varying times ... and I have perhaps forgotten others.
>>
>> It may or may not be obvious but with the platform project we have been
>> deliberately moving more in this direction. There are questions about how
>> dependency management is handled, there are questions about a great number
>> of things actually... but this is certainly a direction that most everyone
>> I've talked to is wanting to go. My initial thought is to organize things
>> at a package level, and have the packages be their own atomic units that can
>> be installed. I think we can achieve this fairly quickly and it would
>> provide a great deal of flexibility around some of the challenges you've
>> touched upon.
>>
>> Since the beginning of this platform project concept I've said that the
>> breadth of what will exist in this project won't be useful for the CMS ....
> How open is the Platform to accepting a refactored library?
Always open. I guess the thing to think about is the Platform is
trying very hard to get off the "CMS" so changes to the installer
should be fairly low level and generic, and I think we'd move a lot of
the custom adapters to the CMS tree (would have to think more on that
one). An example of that is how would one install something via a web
services call (regardless of whether something is a CMS component, or
some hitherto unknown entity, heck Drupal could be connecting to the
API for all we care, the package for installing something should be
able to take care of all the base work "somehow"). The key is working
out what it's supposed to do so that would be great if you can do that
Jeremy.
To answer Gary's question, I think we are all looking at both pull
systems (PEAR, phar, etc) and composition. If you look at the changes
in the application package, you'll see how this is heading with
respect to composition. And yes, interfaces have an ever growing part
to play. You'll see a bit in the UCM as well as the database refactor
branch that is being tested at the moment.
Regards,
Andrew Eddie
__________________________
Gary Glass
On 23 February 2012 08:10, Jeremy Wilken <gnom...@gnomeontherun.com> wrote:
> To be honest, I could care less if we use composition or pull systems, but
> composition probably won't always work. If I need access to a library in my
> component's template file, I'm not going to have a class for composition.
Well that depends on what you are doing but there are definitely parts
of the API that are not intended to be accessed from other parts of
the API. Funnily enough, I think template files are one of the most
abused areas of the developer world because anyone thinks they can do
anything in them … and they do. There is certainly recent work where
we've made it easier to access some data, and harder to access other
data (for example, we tend to default to private variables unless
there is a good case for making them protected, and on rare occasions
public). The net result is that it should be easy to do what you are
supposed to do, and hard to do what you are supposed to be doing in
any given area of the code.
> The challenge is two fold: 1) the code and technical process of managing
> libraries (not my main topic to discuss yet) and 2) the vision and process
> for how libraries should interact with the Platform and CMS.
I cannot stress this enough that you need to think about the Platform
as a basis for any application that someone wants to build on it.
Yes, it was born from the CMS, but it doesn't exist for the pleasure
of just the CMS. That's just one use case - there are many others.
The vision is already much wider than the CMS.
> The second
> challenge needs to be considered before any technical process is designed
> for address the first.
I don't think it figures into the equation at all because library
management applies equally to the CLI developer as it does to someone
writing a game services platform for the iPhone (i.e., no CMS
involvement).
> Look at the numerous 'helper' classes in core
> components, they are often repetitive and ambiguous. Do people agree those
> should be abstracted into libraries and made available?
It depends on which helper you are talking about. The current trend is
to use them less and get away from static usage.
> Should such things
> be part of the CMS or Platform library?
Again, it depends which helpers you are talking about. If you can
specify which ones I can give you some guidance on what might be done
with them.
> Probably the CMS, since the Platform
> trying to be completely separate.
That's not quite accurate. The Platform is trying to devolve itself
of CMS "specific" code that is only useful to someone working in the
CMS (JToolbar, in its current form, is a good example).
> How do we manage two libraries then?
It's already being handled quite nicely thanks to a recent change in
the auto-loader by Louis. See
http://developer.joomla.org/manual/ch01s04.html
You can include any number of libraries that you want that follow the
auto-loader convention (and there are ways around it if they don't
follow convention). However, if you want to add in something like
Zend Framework 2, you are probably on your own though.
> Should people be able to install supporting libraries into those libraries?
> How can we try to limit library duplication? What is the process for making
> a library and how should people find ways to share common dependencies?
I suggest to you that these questions can only be answered on a
case-by-case basis. If you give me an example, I can give you an
opinion about how it might be handled. Though, an umbrella answer is
that if all developers are thinking about what they can contribute
back to the platform core, it makes the discussion a lot easier.
> These are the kinds of questions to discuss first. I mentioned the current
> library for install/update likely needs an overhaul, but that is based on
> the assumption that the best plan of attack for this process requires us to
> rethink the way we do things now.
Do you mean in the sense of install/update like is done in the CMS or
install/update as a standalone platform not tied specifically to any
platform?
Regards,
Andrew Eddie
Just to explain, the /libraries/cms folder in the Platform is
temporary. It's there to show the CMS what we moved so they can more
easily put it in their tree. Just before the release of 12.1 we'll
tag the repository and then remove the /libraries/cms folder (the tag
means anyone can go back and double-check what was removed), and then
the official (and lighter) version of 12.1 will be tagged and
released.
> And about CLI aplications, the JPlatform can maybe do not force use of
> database to handle where are repositories and cache of they. Since is not
> need for CLI aplications fix database, and does not need care about one
> beauty interface with opinion of others, should be a bit more easy. Even if
> not ready for CMS 3.0, could be release as undocumented feature that only
> works on CLI, and, because is not oficially released, could be change a lot
> before of CMS 3.5.
Actually, a lot of CLI's that I've written do support database work.
Yes, you can certainly look at the Joomla Platform as a basket of
undocumented features in whatever application is built on top of it -
that is, until we get the developer manual finished (not so subtle
hint for people to help!). That's the beauty of the separation of the
Platform from the CMS - new developer features can be added much more
quickly.
> But... well, 3.0 should come with more drastic changes than 3.5, so or we
> put this feature on 3.5, or be ***really*** sure that will be stable for
> 3.5. I'm not sure if this kind of feature tend to be well tested by only
> bug squad members.
New platform features, with few exceptions, need to come with
automated tests. That doesn't mean there aren't bugs, but it makes the
code base a lot more reliable.
Thanks for your comments :)
Example: We can also look at Joomla and see the captcha plugins, and see a use case. Currently only ReCaptcha is setup, but any number of captchas could be coded as plugins. We disagree they ought to be plugins, since captcha verification should act like JRequest::checkToken() does on requests and isn't evented. Rather, it would make sense for a Captcha library, with subclasses for specific types of captcha, to be made accessible for applications in their data-validation process. JRequest::checkCaptcha() for example, and I know JRequest is going away but its easier to write for the moment.