Just to follow up on what Niels and Michael have said here, the direction is not to copy/paste code all over the place un-DRY-ing everything. The idea is that separate parts should be separate. Quite a bit of the platform was written to bridge gaps in PHP. Either bridging from PHP4 to PHP5 (eg. JObject, JSimpleXML) or just filling in things we found as holes here and there. In a few places we tried to bridge the gap between PHP installations such as JFTP, which is designed to use the native FTP methods if present and fall back on our own implementation if they are not present. Not all hosts have the FTP extension installed, and we felt it was necessary at the time to make things less painful for lots of new users. As these things become less necessary we will re-evaluate their lease on life.
With respect to Exception messages, I am strongly against having translation within those messages. The reality of the situation is that exception messages are for developers, not users. A well built application will catch exceptions, inspect them, and then either direct or message the user gracefully. As pointed out we don't know if the exception may have occurred within the mechanism to translate the message, or some dependency of that translation mechanism. As a project we are certainly committed to internationalization and localization, but I don't see the reward vs the risk on translating exception messages ... especially at the point where they are thrown.
Lastly, with respect to separation of platform packages, this is something we want to work towards. It isn't an absolute, but it is a principle. Similarly, DRY is a principle. Sometimes it is just insane not to repeat a block of code somewhere else. Other times it is insane to do so. One of our goals is to build the platform in such a way that we can only select the packages we actually need for a project. We'll continue to work towards that end, and also continue to work towards not repeating ourselves. When those two principles conflict we will have to assess, make a judgement call, and move forwards.
So is the long term plan for platform development to break out each package into its own independent PSR-compliant / Composer installable vendor package? (Minus PSR-2, since we already know Joomla's position on that)
On Monday, October 1, 2012 12:27:36 PM UTC-5, Donald Gilbert wrote:
> From another thread that got off topic:
> Quoting Louis:
> Lastly, with respect to separation of platform packages, this is something > we want to work towards. It isn't an absolute, but it is a principle. > Similarly, DRY is a principle. Sometimes it is just insane not to repeat > a block of code somewhere else. Other times it is insane to do so. One of > our goals is to build the platform in such a way that we can only select > the packages we actually need for a project. We'll continue to work > towards that end, and also continue to work towards not repeating > ourselves. When those two principles conflict we will have to assess, make > a judgement call, and move forwards.
I can only speak for myself and say that the direction you suggest is
definitely the direction I want us to head. As for the specifics of being
PSR-compliant and Composer installable I'm not willing to commit to
anything. We could also go the PEAR route as well, or any number of things
actually. I will say that I personally would like to see them in a state
where we can manage dependencies, install them independently, and be
choosey about what we deploy with given applications.
I want us to be very inclusive with respect to the breadth of packages that
we have in the Joomla Platform. There is scope for packages that
consume/utilize web services from all corners of the web, lots of different
types of media management packages (wouldn't a video package, sort of like
the image package, be really cool?), etc. As we expand the scope I want
applications like the Joomla CMS to be able to just choose the ones that
make sense for the CMS instead of having the entire breadth of Joomla
Platform library packages included. That puts us in a place where we need
to think about how extension developers could then install/include other
packages that the base CMS distribution had no need for...
Lots to think about, but the obvious first step is to have us logically
decouple packages that don't need to be coupled. That means thought and
consideration around the tradeoffs of DRY vs decoupled code.
Cheers.
- Louis
On Mon, Oct 1, 2012 at 12:07 PM, Donald Gilbert <dilbert4l...@gmail.com>wrote:
> So is the long term plan for platform development to break out each
> package into its own independent PSR-compliant / Composer installable
> vendor package? (Minus PSR-2, since we already know Joomla's position on
> that)
> On Monday, October 1, 2012 12:27:36 PM UTC-5, Donald Gilbert wrote:
>> From another thread that got off topic:
>> Quoting Louis:
>> Lastly, with respect to separation of platform packages, this is
>> something we want to work towards. It isn't an absolute, but it is a
>> principle. Similarly, DRY is a principle. Sometimes it is just insane not
>> to repeat a block of code somewhere else. Other times it is insane to do
>> so. One of our goals is to build the platform in such a way that we can
>> only select the packages we actually need for a project. We'll continue to
>> work towards that end, and also continue to work towards not repeating
>> ourselves. When those two principles conflict we will have to assess, make
>> a judgement call, and move forwards.
On Mon, Oct 1, 2012 at 5:18 PM, Louis Landry <louislan...@gmail.com> wrote:
> I can only speak for myself and say that the direction you suggest is
> definitely the direction I want us to head. As for the specifics of being
> PSR-compliant and Composer installable I'm not willing to commit to
> anything. We could also go the PEAR route as well, or any number of things
> actually. I will say that I personally would like to see them in a state
> where we can manage dependencies, install them independently, and be
> choosey about what we deploy with given applications.
> I've started packaging the platform up as a PHAR for the applications I
> build. This is one of the reasons I built
> https://github.com/LouisLandry/packager. If you look at the following
> section of the readme,
> https://github.com/LouisLandry/packager#the-packages-element, you will
> see one way I am doing this. There are obviously both advantages and
> disadvantages to doing things this way.
> I want us to be very inclusive with respect to the breadth of packages
> that we have in the Joomla Platform. There is scope for packages that
> consume/utilize web services from all corners of the web, lots of different
> types of media management packages (wouldn't a video package, sort of like
> the image package, be really cool?), etc. As we expand the scope I want
> applications like the Joomla CMS to be able to just choose the ones that
> make sense for the CMS instead of having the entire breadth of Joomla
> Platform library packages included. That puts us in a place where we need
> to think about how extension developers could then install/include other
> packages that the base CMS distribution had no need for...
> Lots to think about, but the obvious first step is to have us logically
> decouple packages that don't need to be coupled. That means thought and
> consideration around the tradeoffs of DRY vs decoupled code.
> Cheers.
> - Louis
> On Mon, Oct 1, 2012 at 12:07 PM, Donald Gilbert <dilbert4l...@gmail.com>wrote:
>> So is the long term plan for platform development to break out each
>> package into its own independent PSR-compliant / Composer installable
>> vendor package? (Minus PSR-2, since we already know Joomla's position on
>> that)
>> On Monday, October 1, 2012 12:27:36 PM UTC-5, Donald Gilbert wrote:
>>> From another thread that got off topic:
>>> Quoting Louis:
>>> Lastly, with respect to separation of platform packages, this is
>>> something we want to work towards. It isn't an absolute, but it is a
>>> principle. Similarly, DRY is a principle. Sometimes it is just insane not
>>> to repeat a block of code somewhere else. Other times it is insane to do
>>> so. One of our goals is to build the platform in such a way that we can
>>> only select the packages we actually need for a project. We'll continue to
>>> work towards that end, and also continue to work towards not repeating
>>> ourselves. When those two principles conflict we will have to assess, make
>>> a judgement call, and move forwards.
I agree with that but also I would say that you should in general have the worst case scenario in mind. So even if you have an application that uses JText, what if something happens to it? In that case you get an infinite loop of exceptions triggering JText exceptions ... which I think we actually handled at some point but still, there is really only potential trouble there.
On Monday, October 1, 2012 4:24:58 PM UTC-4, Júlio Pontes wrote:
> I Agree with Louis++.
> On Mon, Oct 1, 2012 at 5:18 PM, Louis Landry <louis...@gmail.com<javascript:>
> > wrote:
>> I can only speak for myself and say that the direction you suggest is >> definitely the direction I want us to head. As for the specifics of being >> PSR-compliant and Composer installable I'm not willing to commit to >> anything. We could also go the PEAR route as well, or any number of things >> actually. I will say that I personally would like to see them in a state >> where we can manage dependencies, install them independently, and be >> choosey about what we deploy with given applications.
>> I've started packaging the platform up as a PHAR for the applications I >> build. This is one of the reasons I built >> https://github.com/LouisLandry/packager. If you look at the following >> section of the readme, >> https://github.com/LouisLandry/packager#the-packages-element, you will >> see one way I am doing this. There are obviously both advantages and >> disadvantages to doing things this way.
>> I want us to be very inclusive with respect to the breadth of packages >> that we have in the Joomla Platform. There is scope for packages that >> consume/utilize web services from all corners of the web, lots of different >> types of media management packages (wouldn't a video package, sort of like >> the image package, be really cool?), etc. As we expand the scope I want >> applications like the Joomla CMS to be able to just choose the ones that >> make sense for the CMS instead of having the entire breadth of Joomla >> Platform library packages included. That puts us in a place where we need >> to think about how extension developers could then install/include other >> packages that the base CMS distribution had no need for...
>> Lots to think about, but the obvious first step is to have us logically >> decouple packages that don't need to be coupled. That means thought and >> consideration around the tradeoffs of DRY vs decoupled code.
>> Cheers.
>> - Louis
>> On Mon, Oct 1, 2012 at 12:07 PM, Donald Gilbert <dilber...@gmail.com<javascript:>
>> > wrote:
>>> So is the long term plan for platform development to break out each >>> package into its own independent PSR-compliant / Composer installable >>> vendor package? (Minus PSR-2, since we already know Joomla's position on >>> that)
>>> On Monday, October 1, 2012 12:27:36 PM UTC-5, Donald Gilbert wrote:
>>>> From another thread that got off topic:
>>>> Quoting Louis:
>>>> Lastly, with respect to separation of platform packages, this is >>>> something we want to work towards. It isn't an absolute, but it is a >>>> principle. Similarly, DRY is a principle. Sometimes it is just insane not >>>> to repeat a block of code somewhere else. Other times it is insane to do >>>> so. One of our goals is to build the platform in such a way that we can >>>> only select the packages we actually need for a project. We'll continue to >>>> work towards that end, and also continue to work towards not repeating >>>> ourselves. When those two principles conflict we will have to assess, make >>>> a judgement call, and move forwards.
