Joomla 2.0

[Herman Peeren]

Joomla! 2.0

I know: 1.6 is still in Alpha-2 today (or did I miss something: just
saw a tweet, from 12 hours ago: "trying out Joomla 1.6 beta"). Some
people think 1.6 will come soon (this book is supposed to be released
half of February: http://www.computerboek.nl/boek/9789012581301/basiscursus_joomla_1.6_eric_tiggeler).
You can even win a "very special prize" predicting the exact release
date (http://brian.teeman.net/joomla-gps/when-will-joomla-16-be-
released.html). There has been some talking about 1.7 during the
Joomla! Developers Conference December 5th, whereupon I saw a Twitter-
comment "Get 1.6 done. Then talk 1.7" (http://twitter.com/
johanjanssens/status/6409910105). But still, we can think ahead: where
do we want to go, what is the horizon, the direction, the aim. Not in
detail, but the big picture.

Some ideas I, as a developer, have about Joomla!:

1. once we have ACL, there is no need anymore for the distinction
between frontend and backend.
2. we need some fundamental OOP-redesign for better code reuse.
3. extensions should only be allowed if they strictly use an API to
the Joomla!-Framework.
4. the central role of the menu could be revised

* ad 1. It is a trend in CMS-land (e.g. DotNetNuke in the transition
from version 4 to 5). Drupal is closer at home as an example here. If
you have rights to edit something, it doesn't matter if you come the
frontend, backend... or the sideline.

* ad 2. I think these symptoms are related: 'cannot override
everything', 'cannot extend a component' and 'so many static methods'.
You can now only override the html-templates of a view. And even then:
you'll have to copy the original file if you want to preserve some of
the original functionality. If you want to add something to a
component, you'll have to make a new component, copying the original
one and adding/changing the things you need. That is a bad "code
smell": extending and reusing should be something else than copying.
That there are so many static methods in the framework could be a
symptom that the original design was more procedural than OOP.

Thinking about a RESTful API for Joomla! I realised, that RESTful-
thinking is not just a fancy way to add webservices to your
application, but also an architectural choice: you minimise the tasks
("verbs") to CRUD and make resources ("nouns") of the rest. Ultimately
it is about restructuring the objects.

* ad 3. A lot of the vulnarabilities in Joomla!-extensions (http://
docs.joomla.org/Vulnerable_Extensions_List) are caused by SQL-
injection. If all database access and user interaction would only be
possible if it is strictly done via the Joomla!-framework, then we can
avoid those weaknesses. The use of filters for JRequest::getVar()
should be obligate. The new JDatabaseQuery (or how was it called?)
could become a database-layer that shields all database-access; if an
extension has to use that layer in stead of making direct sql-
statements, then some vulnarabilities can be totally solved by the
framework.

* ad 4. Some modules depend more on articles than menu-items.
Sometimes the distinction between components and modules gives all
kinds of problems. There are several extensions trying to fix issues
with modules/components/menus. Maybe we should have a look at it again
and think about other ways to organise the content. Maybe tagging
content and then use those tags to structure menus? My thoughts about
this are still vague, but maybe someone has a bright vision.

More ideas?
If you have any ideas about those subjects or have other opinions
about where Joomla! could go to, I'm very interested: please post it.
This is certainly not meant as critic, but as a look from some
distance, to see in what direction I would like to contribute. It is
also not meant as dogma: these are just my ideas at the moment, but I
would be glad to change them for better ones.

[Oli Griffiths]

Hey Herman,

I definitely second your ideas about the menu system. Infact this is
something I was discussing with Louis Landry last year.

We need to get away from a menu-centric design and towards a content-centric
design, using menus only to provide additional links to things, not to be
the main backbone of the site structure. Itemid is the bain of my life
(especially when it comes to sef url components like Artio). It limits what
you can do majorly. Ever wanted to assign a module just to a single article?
Or a single product in a shop. Without a menu item is a lot more difficult.

The unified content structure for 2.0 was thrown about, whereby the content
is at the center of everything. Everything is content, articles, properties,
listings, products etc all work off a central database and can be extended
with additional content type specific options (photos, extra fields etc).
Much like the content construction kits that are available today.

That way we can do away with the menu system at present and only use it to
provide additional links.

You will also be able to produce a menu structure for your site that mimics
your content structure (something that is definitely missing in joomla, and
a reason why we've had clients use wordpress instead). I know there are
modules that do a similar thing, but the current Itemid issue causes many
problems with this.

Id like to see a system where most components are merely extensions of the
core content system. So, if for example you have a listings directory
component installed, you could go to admin > content > new content > select
content type (directory listing) and the page is loaded with all the options
to create directory listings.

The idea of "pages" then comes into play. One could create a "page" (which
is the same way that most people think of the internet) and you can choose
what appears on that page, from the page rather than having to go to various
parts of the admin to configure it. You can select modules XYZ, banner 2,
template A, article 219, 229, 482 and 332 and set it to display using a
particular layout (which should be extendable/overrideable) that will
control how the page is laid out (eg blog).

You could even go as far as these pages being able to pull in multiple bits
of content based on keyword/filter options. For example say I want to create
a page that display all content that is an article, has been created in the
last month by user "fred".

The core idea is that content is the center of everything and you provide
various way that the user can view/access that content.

Whats peoples thoughts on this?

Oli

[Hannes Papenberg]

to 1.: I think you definitely need a backend, especially one where you
can have a complete overview of all articles and don't have to move
through the whole site to make sure that you found every article that
you needed to edit/delete or similar stuff. There are maybe a few
web-applications that do not use a backend, but if I look through my
list of web-applications (blogging software, CMS, forums) there are
maybe 30 applications where only 2 or 3 have no backend.

to 2.: You can easily override models, views, layouts, libraries,
modules and plugins already in 1.5. The only thing missing in 1.5 is the
controller, which you can now override in 1.6. I would also disagree
with the statement, that Joomla has a lot of static functions. Joomla
has basically two types of static functions, singletons to only create
one instance of an object and static functions that are shortcuts for
some HTML output. Otherwise, Joomla is very much along the lines of OOP.
I don't think that we are really lacking here.

to 3.: We can't enforce that. There is no way in PHP to prevent anyone
from using the built in functions or to force them to stick to a coding
scheme.

to 4.: This is already planned.

Hannes

[Júlio Pontes]

some ideas for Joomla 2.0

http://www.alltogetherasawhole.org/profiles/blogs/joomla-idea
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/53b3182d5f644886
http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/ea494a7bdd2da241

[Herman Peeren]

Thank you for your quick answers.

@1. I didn't mean a distinction between frontend and backend *
functionality * , but the seperate administrator-folder with its own
objects. Now, when writing frontend fuctionality and you want to use
some logic that is also used in the backend, you have to use your
backend model or copy code. Or am I doing that the wrong way? Wouldn't
it be great if you just have components that do something with the
data and you can use those components as you like to make a frontend,
backend or whatever end you would call it?

@2 I'd like to see some examples of how others are easily overriding
views, layouts, libraries, modules and plugins. And I definitely will
have a closer look at how that is done in 1.6. Still quite a
difference between overriding and extending classes.

@3 I mean: many exploits can be avoided if we define a clear interface
to which all Joomla!-extensions should adhere (and a seperate database
layer that handles the db-queries). Of course, everybody if free to
write their own things, but if it doesn't meet the minimum (and clear)
security demands, then maybe it should not be allowed to call it a
Joomla!-extension nor to be listed in the JED; I think this is
(even ;-) ) more important for the name of Joomla! (of which I often
hear that it has a bad reputation concerning security) than the GPL-
compliance. I don't want to come on anybodies freedom to build
whatever she/he wants, but we, together, can make some restrictions
for people to add the extension as an official Joomla!-extension. A
framework should make it very easy to fulfil the safety requirements
and maybe the Joomla!-framework could be extended even more in this
direction. And of course, we could develop some software to scan an
extension on the proper use of the API (for which the GPL will come in
handy).

@4 "This is already planned". Great! Can I find some details about it
somewhere allready? Sorry for not having looked properly, didn't find
much about it yet. Is it still open to discussion? How does it relate
to the things Oli just mentioned? For which version is it allready
planned?

[Hannes Papenberg]

@1: feel free to create a component that works only in the frontend and
has all its functionality there. There are several advantages in having
the administrator as its own application and not mashed into the frontend.

@2:
http://community.joomla.org/blogs/community/521-did-you-know-overrides-are-not-just-for-html.html

@3: This would mean that each and every extension and each and every
version of that extension would have to be reviewed by at least one
impartial person in the JED team. We don't even have enough people to
review the new submissions to the JED, let alone the code.

@4: Its planned for 2.0. But before 2.0, we will have 1.7, 1.8, 1.9,
maybe 1.10, 1.11, etc.

Hannes

[Herman Peeren]

Thanks for the links Júlio. I had missed some of those links; I should
have looked better! I'll look through all your posts on several fora
again. Really interesting.

[Oli Griffiths]

@3: Could you not do a basic string check on the package, check for
$_REQUEST and other environment variables, direct db calls using
mysql_connect() etc, and any other specifics that could be part of an
evaluation process. If any of them come back as true, then it needs to be
manually reviewed, or could be automatically declined with a note to the
developer of the issues encountered.

?

[Herman Peeren]

Thanks, Hannes, really useful information. And: wow, you are really a
quick replier!

One thing: I could be wrong, but your replies look a bit defensive to
me. No need for that, for I didn't mean to be agressive at all. I am
just thinking and want to share my thoughts, even if I would be
totally wrong, get fresh input from others and come further together.

I'll delve in it a bit deeper. Sorry if I would say something you
allready thought of.

[Herman Peeren]

@Oli: that kind of automatic check was exactly what I was thinking
about.

Only: at the moment this is not yet very usefull as when you use the
db you still have to make your own queries and are allowed to directly
put a JRequst::getVar() in your querystring. Binding the data to a
JTable is better, but not everything can be done that way now (or at
least: not easily).

Still: it is a good idea if we start buiding a basic scan for
extensions to filter at least some things allready. We can get some
experience with it and expand the tool later.

[Gary Brooks]

@3  We ran into large issue that 3rd party extension developers have stopped us from advancing the Joomla! database driver technology.     In our environment we run shared clusters built for Joomla!.    The goal was replicate MySQL server, fork Joomla! database driver, and have  ability  load balance and fail safe the Joomla! application in a cluster.  We had great success completing this task.    Then we installed applications like RSforms that work outside of the framework and the mission came to a grinding halt.    

Anything we could do to force proper Joomla! coding standards would be a big +1 vote from me.      We can not responsibly scale Joomla! without all the 3rd party devs following all the rules.

Gary Brooks

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Amy Stephen]

Gary -

If you are able to explain for folks why "straying from the framework"
means their extensions are likely not going to work with other
solutions, such as your Cloud solutions, then, those arguments are the
best motivation to color in the lines. Might want to consider a
Magazine article or a blog post of some sort. I am interested in
hearing more about this situation, too.

Thanks.
Amy

On Jan 24, 11:28 am, Gary Brooks <garyjaybro...@gmail.com> wrote:
> @3  We ran into large issue that 3rd party extension developers have stopped
> us from advancing the Joomla! database driver technology.     In our
> environment we run shared clusters built for Joomla!.    The goal was
> replicate MySQL server, fork Joomla! database driver, and have  ability
> load balance and fail safe the Joomla! application in a cluster.  We had
> great success completing this task.    Then we installed applications like
> RSforms that work outside of the framework and the mission came to a
> grinding halt.
>
> Anything we could do to force proper Joomla! coding standards would be a big
> +1 vote from me.      We can not responsibly scale Joomla! without all the
> 3rd party devs following all the rules.
>
> Gary Brooks
>

> On Sun, Jan 24, 2010 at 10:00 AM, Herman Peeren <herman.pee...@gmail.com>wrote:
>
> > @Oli: that kind of automatic check was exactly what I was thinking
> > about.
>
> > Only: at the moment this is not yet very usefull as when you use the
> > db you still have to make your own queries and are allowed to directly
> > put a JRequst::getVar() in your querystring. Binding the data to a
> > JTable is better, but not everything can be done that way now (or at
> > least: not easily).
>
> > Still: it is a good idea if we start buiding a basic scan for
> > extensions to filter at least some things allready. We can get some
> > experience with it and expand the tool later.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! General Development" group.
> > To post to this group, send an email to
> > joomla-de...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > joomla-dev-gene...@googlegroups.com<joomla-dev-general%2Bunsu...@googlegroups.com>

[Mike McGinn]

On database issues:

Is anyone factoring in the long term effects of  "Oracle bought Sun for MySQL code"  issue?

Perhaps developing/supporting a fork of MySQL to insure our project's appeal does not get nixed because the GPL licenses get changed.

Just a long range thought....  In Joomla 3.0 maybe Joomla becomes a virtual appliance like TurnKey apps with our fork of MySQL embedded in it.


--
Michael Scott McGinn
http://www.waptug.org
http://mycmshosting.peoplelex.com

[Herman Peeren]

A seperate database layer could also diminish the dependence on one
single DBMS.

Different plugins for the db-layer , so you can choose what db you
want to use... (probably won't be there before Joomla! 4.0).

[Mike McGinn]

Great Idea. Middle layer with database interfacing and filtering for any and all rdbm's

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Hannes Papenberg]

Did you look at 1.6?

Hannes

Am 24.01.2010 22:10, schrieb Mike McGinn:
> Great Idea. Middle layer with database interfacing and filtering for
> any and all rdbm's
>
> On Sun, Jan 24, 2010 at 1:04 PM, Herman Peeren
> <herman...@gmail.com <mailto:herman...@gmail.com>> wrote:
>
> A seperate database layer could also diminish the dependence on one
> single DBMS.
>
> Different plugins for the db-layer , so you can choose what db you
> want to use... (probably won't be there before Joomla! 4.0).
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! General Development" group.
> To post to this group, send an email to
> joomla-de...@googlegroups.com

> <mailto:joomla-de...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-gene...@googlegroups.com

> <mailto:joomla-dev-general%2Bunsu...@googlegroups.com>.

[Mike McGinn]

I have installed an early alpha. 

on another note:  maybe Oracle has a nice rdbms to develop a DB middle layer for.

http://oss.oracle.com/oracle-database-xe.html

[Hannes Papenberg]

I'm just saying, since this is all already in 1.6.

Hannes

Am 24.01.2010 22:45, schrieb Mike McGinn:
> I have installed an early alpha.
>
> on another note: maybe Oracle has a nice rdbms to develop a DB middle
> layer for.
>
> http://oss.oracle.com/oracle-database-xe.html
>
> On Sun, Jan 24, 2010 at 1:21 PM, Hannes Papenberg
> <hack...@googlemail.com <mailto:hack...@googlemail.com>> wrote:
>
> Did you look at 1.6?
>
> Hannes
>
> Am 24.01.2010 22:10, schrieb Mike McGinn:
> > Great Idea. Middle layer with database interfacing and filtering for
> > any and all rdbm's
> >
> > On Sun, Jan 24, 2010 at 1:04 PM, Herman Peeren
> > <herman...@gmail.com <mailto:herman...@gmail.com>

> <mailto:herman...@gmail.com <mailto:herman...@gmail.com>>>

> wrote:
> >
> > A seperate database layer could also diminish the dependence
> on one
> > single DBMS.
> >
> > Different plugins for the db-layer , so you can choose what
> db you
> > want to use... (probably won't be there before Joomla! 4.0).
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "Joomla! General Development" group.
> > To post to this group, send an email to
> > joomla-de...@googlegroups.com
> <mailto:joomla-de...@googlegroups.com>

> > <mailto:joomla-de...@googlegroups.com

> <mailto:joomla-de...@googlegroups.com>>.
> > To unsubscribe from this group, send email to
> > joomla-dev-gene...@googlegroups.com
> <mailto:joomla-dev-general%2Bunsu...@googlegroups.com>

> > <mailto:joomla-dev-general%2Bunsu...@googlegroups.com
> <mailto:joomla-dev-general%252Buns...@googlegroups.com>>.

[Mike McGinn]

Sounds like a good Google Summer of Code Project idea.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Herman Peeren]

Yes, talking about a database-layer: interesting development in that
direction in 1.6 is the new JDatabaseQuery class.

Andrew gave a presentation about it on the Dev. Conf. December 5th in
NYC. See videos on http://www.ustream.tv/channel/joomla-developer-conference-nyc-2009
and with better sound on http://zunostudios.com/blogs/tags/jdc09/ .
Discussion about the name of the class a.o. on
http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/f9a0e90909057c87

[Herman Peeren]

O, eh, in the JDC-videos the JDatabaseQuery-class is still called
JQuery, which fortunately was corrected afterwards.

Maybe this could eventually become the part of the framework I was
referring to as the layer for all database-access. Then our scan-tool
for Joomla!-security could check if an extension uses it everywhere.
I'll have a closer look at the class.

[Herman Peeren]

For completeness: in the 1.6 Alpha-2 source the name of the mentioned
class also still is JQuery (in libraries/joomla/database/query.php).

[Herman Peeren]

Last spam for today: Andrew's JQuery Video (http://www.ustream.tv/
recorded/2717832) is unfortunately not also available in better
quality. But you can get the idea from it.

[Mike McGinn]

Sweet.  I haven't dove in to the under the hood of 1.6 yet to know that.  Cool. Thanks for the word up on that.

[Andrew Godziuk]

> to 2.: You can easily override models, views, layouts, libraries,
> modules and plugins already in 1.5. The only thing missing in 1.5 is the
> controller, which you can now override in 1.6.

Overriding is not the solution here. You can't extend a class - you
need to override it. Which, in practical terms, means that you need to
make a copy, make your changes and override the original. In OOP you
would inherit.

Think what happens when the original class introduces a security fix
and you're running an overridden old copy.

> I would also disagree
> with the statement, that Joomla has a lot of static functions. Joomla
> has basically two types of static functions, singletons to only create
> one instance of an object and static functions that are shortcuts for
> some HTML output. Otherwise, Joomla is very much along the lines of OOP.
> I don't think that we are really lacking here.

More *documented* hooks or other ways to extend functionality need to
be added, to prevent the overriding disease. A good example is the
task I performed recently - I helped to write a plugin that handled
404s. All the other plugins use patching of JError, which is not very
elegant. The code in JError, however, allows to plug custom behaviour
without modifying core. But it means injecting your error handler in
some obscure global variable, which is not too much OOP, and definitly
not documented.

> to 3.: We can't enforce that. There is no way in PHP to prevent anyone
> from using the built in functions or to force them to stick to a coding
> scheme.

This is unfortunately true. We have had a problem with RSForms that
happily used mysql_query for all database operations, and I wrote a
bitter blog post about it but it must have been to bitter to appear on
our company blog ;)

--
Andrzej Godziuk
http://CloudAccess.net/

[Niels Braczek]

Andrew Godziuk schrieb:

>> to 2.: You can easily override models, views, layouts, libraries,
>> modules and plugins already in 1.5. The only thing missing in 1.5 is the
>> controller, which you can now override in 1.6.
>
> Overriding is not the solution here. You can't extend a class - you
> need to override it. Which, in practical terms, means that you need to
> make a copy, make your changes and override the original. In OOP you
> would inherit.
>
> Think what happens when the original class introduces a security fix
> and you're running an overridden old copy.

It is possible to inherit from (or - what I prefer - decorate) the core
classes, although it is a bit tricky. I needed that for system-wide
customization of the email handling. In a system plugin, I have

public function onAfterInitialise()
{
// Rename the orginal JMail class to JMailOrignal to avoid
// naming conflict.
// This is necessary, because the design of JFactory makes
// it impossible to apply decorators the conventional way.
$string = file_get_contents( JPATH_LIBRARIES .
'/joomla/mail/mail.php');
$string = preg_replace( '~\bJMail\b~', 'JMailOriginal', $string );

// JMail class does not close php mode so we may not reopen it
eval( '?>'.$string );

// get our own JMail decorator class
require_once JPATH_PLUGINS .
'/system/nx_mailTemplate/nxmail_decorator.class.php';
$mail = new JMail( JMailOriginal::getInstance() );
}

Thus, JFactory still can use JMail, but now talks to the new class,
which delegates any call (eventually modified) to the original class.

The decoration or replacement of core classes would be much easier, if
JFactory created real singletons and not were a prototype factory. With
a real singleton, decoration were as easy as

$mail = JFactory::getMailer();
$mail = new MyMailDecorator( $mail );

without the need to use string replacement and eval().

Regards,
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Ian MacLennan]

On Mon, Jan 25, 2010 at 8:44 AM, Andrew Godziuk <and...@cloudaccess.net> wrote:

> to 2.: You can easily override models, views, layouts, libraries,
> modules and plugins already in 1.5. The only thing missing in 1.5 is the
> controller, which you can now override in 1.6.

Overriding is not the solution here. You can't extend a class - you
need to override it. Which, in practical terms, means that you need to
make a copy, make your changes and override the original. In OOP you
would inherit.

I would agree with this.  I mean, there are many things that are possible in Joomla! 1.5, but it is certainly not ideal to have people overriding classes all over the place.  You lose the benefit of core updates if the overridden class happens to receive an update.

OOP is designed for this.  I don't have an easier answer in the current framework and way we do things, but I think this is a problem worth thinking about.

 

Think what happens when the original class introduces a security fix
and you're running an overridden old copy.

Oh, didn't see this until after.  I guess that is exactly the point I made above.
 

> I would also disagree
> with the statement, that Joomla has a lot of static functions. Joomla
> has basically two types of static functions, singletons to only create
> one instance of an object and static functions that are shortcuts for
> some HTML output. Otherwise, Joomla is very much along the lines of OOP.
> I don't think that we are really lacking here.

More *documented* hooks or other ways to extend functionality need to
be added, to prevent the overriding disease. A good example is the
task I performed recently - I helped to write a plugin that handled
404s. All the other plugins use patching of JError, which is not very
elegant. The code in JError, however, allows to plug custom behaviour
without modifying core. But it means injecting your error handler in
some obscure global variable, which is not too much OOP, and definitly
not documented.

Sadly, there are many things you can do with the framework that aren't widely known or well documented.  Improving this going forward is definitely necessary.
 

> to 3.: We can't enforce that. There is no way in PHP to prevent anyone
> from using the built in functions or to force them to stick to a coding
> scheme.

This is unfortunately true. We have had a problem with RSForms that
happily used mysql_query for all database operations, and I wrote a
bitter blog post about it but it must have been to bitter to appear on
our company blog ;)

There isn't much we can do about the mysql calls without trying to hide the database information somehow, which is not a good solution.  We have considered the idea of killing the GET, POST and COOKIE superglobals to really encourage people to use JRequest, which could encourage secure extensions.

Ian
 

--
Andrzej Godziuk
http://CloudAccess.net/

[Andrew Godziuk]

On Mon, Jan 25, 2010 at 3:29 PM, Niels Braczek <nbra...@bsds.de> wrote:
> Andrew Godziuk schrieb:

> It is possible to inherit from (or - what I prefer - decorate) the core
> classes, although it is a bit tricky. I needed that for system-wide
> customization of the email handling. In a system plugin, I have

> (...)

This is an interesting technique!

It, however, shows that you need to do hacky things to achieve results
that should be simple to do.

>
> The decoration or replacement of core classes would be much easier, if
> JFactory created real singletons and not were a prototype factory. With
> a real singleton, decoration were as easy as
>
> $mail = JFactory::getMailer();
> $mail = new MyMailDecorator( $mail );
>
> without the need to use string replacement and eval().

I would go this way:
// in plugin
class BetterMail extends JMail {...};
JFactory::setMailerClass('BetterMail');
// in application
$mail = JFactory::getMailer(); // returns BetterMail instance

[Andrew Godziuk]

On Mon, Jan 25, 2010 at 3:50 PM, Ian MacLennan <ian.ma...@joomla.org> wrote:

>> More *documented* hooks or other ways to extend functionality need to
>> be added, to prevent the overriding disease. A good example is the
>> task I performed recently - I helped to write a plugin that handled
>> 404s. All the other plugins use patching of JError, which is not very
>> elegant. The code in JError, however, allows to plug custom behaviour
>> without modifying core. But it means injecting your error handler in
>> some obscure global variable, which is not too much OOP, and definitly
>> not documented.
>>
> Sadly, there are many things you can do with the framework that aren't
> widely known or well documented.  Improving this going forward is definitely
> necessary.

It's true. But it's also a flaw in design - why would anyone store
handlers in global variables? There should be metods exposed like
addErrorHandler or likewise. There was a lot of buzz about Joomla 1.5
using observer pattern everywhere, and this surprised me. Maybe 2.0 is
good time to fully shift to OOP.

> There isn't much we can do about the mysql calls without trying to hide the
> database information somehow, which is not a good solution.  We have
> considered the idea of killing the GET, POST and COOKIE superglobals to
> really encourage people to use JRequest, which could encourage secure
> extensions.

Maybe Joomla.org could put some pressure on extension vendors? I know
that some review work is done before extension is submitted to JED -
maybe the reviewers should be supplied with some basic code review
tool? Simpley grepping for mysql_query and _GET and other similar
construct could give a warning.

Bad extensions could be somehow marked or removed from JED. Just an
idea, though, and far from topic of J! 2.0.

[Niels Braczek]

Andrew Godziuk schrieb:

> On Mon, Jan 25, 2010 at 3:29 PM, Niels Braczek <nbra...@bsds.de> wrote:

>> Andrew Godziuk schrieb:
>> It is possible to inherit from (or - what I prefer - decorate) the core
>> classes, although it is a bit tricky. I needed that for system-wide
>> customization of the email handling. In a system plugin, I have
>> (...)
>
> This is an interesting technique!
>
> It, however, shows that you need to do hacky things to achieve results
> that should be simple to do.

But is the only possible way, when the caller (JFactory) uses absolute
names.

>> $mail = JFactory::getMailer();
>> $mail = new MyMailDecorator( $mail );
>>
>> without the need to use string replacement and eval().
>
> I would go this way:
> // in plugin
> class BetterMail extends JMail {...};
> JFactory::setMailerClass('BetterMail');
> // in application
> $mail = JFactory::getMailer(); // returns BetterMail instance

The simple assignment does all the job, because of objects always being
assigned by reference. Next time, JFactory::getMailer() is called, it
would return the decorated mailer.

Decorator is better than inheritance, because it is much more flexible.
Think of the database class. In an ideal world, Joom!Fish will decorate
the class to add translation. An Oracle decorator will add tha ability
to talk MySQl to an Oracle DB. Another decorator might be able to handle
distributed tables.

So, with decorators, you have the original class and 3 extending
classes, and are able to combine any of them. Makes n extra classes for
n combinable features.

To achieve the same with inheritance, you need the original class, a
JoomFish descendant. For both of them you need Oracle descendant, making
up 4 classes. To support distributed tables, 4 more descendants are
needed. Thus, it makes 2^n-1 extra classes for n features. In reality,
many combinations will not be implemented.

[Andrew Godziuk]

On Mon, Jan 25, 2010 at 4:29 PM, Niels Braczek <nbra...@bsds.de> wrote:
> Andrew Godziuk schrieb:

> The simple assignment does all the job, because of objects always being
> assigned by reference. Next time, JFactory::getMailer() is called, it
> would return the decorated mailer.
>

Wouldn't JFactory still keep reference to old mail object?

> Decorator is better than inheritance, because (...)

It's a matter of approach, in the cases you mentioned it is indeed better.

My point here is that Joomla should allow to easily extend existing
classes. Both decoration and inheritance and possibly other approaches
would be possible then.

[Niels Braczek]

Andrew Godziuk schrieb:

> On Mon, Jan 25, 2010 at 4:29 PM, Niels Braczek <nbra...@bsds.de> wrote:

>> The simple assignment does all the job, because of objects always being
>> assigned by reference. Next time, JFactory::getMailer() is called, it
>> would return the decorated mailer.
>
> Wouldn't JFactory still keep reference to old mail object?

To be clear: The simple

$mail = JFactory::getMailer();
$mail = new MyMailDecorator( $mail );

does not work as JFactory is designed now.

But if it would return a singleton, the internal reference of the mailer
in JFactory would be the very same as $mail. Changing $mail would thus
also change the internal reference.

>> Decorator is better than inheritance, because (...)
>
> It's a matter of approach, in the cases you mentioned it is indeed better.

And it has no drawbacks compared to inheritance. Using __call,
__callstatic, __set, and __get (where appropriate), a decorator is very
easy to set up.

> My point here is that Joomla should allow to easily extend existing
> classes. Both decoration and inheritance and possibly other approaches
> would be possible then.

Yes, but it has to be ensured, that one extension does not disturb
another. That is not possible on class level (inheritance), but it is on
object level (decoration).

Again, see the database class. If JoomFish inherits from JDatabase, and
you want to use the Oracle class, you're lost, since the Oracle class
would inherit form JDatabase, too, and not from JoomFish's database. You
can only use one of them at a time. With decorators, you can put
decorator on decorator on decorator ... without any problems. Therefore,
the decorator should be the preferred way to extend core objects.

[Oli Griffiths]

Had a thought about this one.

As a temporary measure whilst a more suitable way is worked out, could one
not do

$mail =& Jfactory::getMailer()
$mail = new myMailDecorator( $mail )

Then and forever more in the code doing Jfactory::getMailer() would return
your mailer instance, not the original as the method is referenced to a
static internal variable within jfactory?

Oli

[Niels Braczek]

Oli Griffiths schrieb:

> As a temporary measure whilst a more suitable way is worked out, could one
> not do
>
> $mail =& Jfactory::getMailer()

^
This is no longer needed. It is a PHP4 relict.

> $mail = new myMailDecorator( $mail )

> Then and forever more in the code doing Jfactory::getMailer() would return
> your mailer instance, not the original as the method is referenced to a
> static internal variable within jfactory?

JFactory::getMailer() builds a single empty instance of the mailer and
uses it as a prototype. Every call to JFactory::getMailer() returns a
clone of that prototype. The instance is kept in a local static
variable, so it is not possible to replace the instance without the
trick, I showed before.

[Andrew Godziuk]

>> Wouldn't JFactory still keep reference to old mail object?
>
> To be clear: The simple
>
> $mail = JFactory::getMailer();
> $mail = new MyMailDecorator( $mail );
>
> does not work as JFactory is designed now.
>
> But if it would return a singleton, the internal reference of the mailer
> in JFactory would be the very same as $mail. Changing $mail would thus
> also change the internal reference.

I somehow can't imagine it but it may be my lack of knowledge in PHP's
model of handling references, so I can't comment on this one :)

> And it has no drawbacks compared to inheritance. Using __call,
> __callstatic, __set, and __get (where appropriate), a decorator is very
> easy to set up.
>
>> My point here is that Joomla should allow to easily extend existing
>> classes. Both decoration and inheritance and possibly other approaches
>> would be possible then.
>
> Yes, but it has to be ensured, that one extension does not disturb
> another. That is not possible on class level (inheritance), but it is on
> object level (decoration).
>
> Again, see the database class. If JoomFish inherits from JDatabase, and
> you want to use the Oracle class, you're lost, since the Oracle class
> would inherit form JDatabase, too, and not from JoomFish's database. You
> can only use one of them at a time. With decorators, you can put
> decorator on decorator on decorator ... without any problems. Therefore,
> the decorator should be the preferred way to extend core objects.
>

I didn't say that compositing is inferior to inheritance and the
database translator layer is definitely the example. I don't care
which method would be chosen as long as it would be possible.

Anyway:
$basename = JFactory::getMailerClass();
class MyEvenBetterMailer extends $basename {...};
would do the stacking trick too.

[Niels Braczek]

Andrew Godziuk schrieb:

> Anyway:
> $basename = JFactory::getMailerClass();
> class MyEvenBetterMailer extends $basename {...};
> would do the stacking trick too.

Not really:
Parse error: syntax error, unexpected T_VARIABLE, expecting T_STRING ...

[ssnobben]

1. Get rid of (sections) categories and only use menu(s) + menu
module(s). Can anyone explain w h y we need them? Its not logical at
all to use them or pls explain. Still after more than 4 years with
Joomla I dont understand the meaning with them...
http://forum.joomla.org/viewtopic.php?f=500&t=273958&start=90

2. Why have Joomla choosen Mootools over Jquery (Drupal) ? Can anyone
explain why we/Joomla uses Mootools instead of Jquery and all the
problem for everyone it creates?

3. Make a CCK like SeblodCCK ? into core of Joomla 1.7 already (like
Drupal again..) http://www.jseblod-cck.com/features/universal-compatibility.html

Well thats all for now. :)

[Ryan Briscall]

Heh,

I've been using the Section Manager as a flag for special actions.
For example, when I want certain articles to be special items, then I
assign those articles to a section called "Gallery" for example. Then
I hack joomla to do special stuff to the articles, only if the
articles are from that section.

Meh,

[dukeofgaming]

Hey ssnobben,

1.- There should be use cases considered for this. I don't know what kind of sites you build/implement but for an article site this is imperative IMO.

2.- Seems our JOverlords have taken the mootools stance on this: http://jqueryvsmootools.com/ . I personally find Mootools to be the best framework for making Javascript a better programming language (since it modifies native prototypes) and not just doing flashy/ajaxy things.

3.- Check Flexicontent, we do need something like that!. With its article templates and custom fields and multicategories and plugins and tags and... and... =)

Regards

[klas....@gmail.com]

It would be better to approach it the other way around - drop menu's as building structure an keep it just as shortcuts to whatever they are pointing to.

IMHO Menu driven approach is one of the biggest architectural mistakes in Joomla causing constant clashes with internal component structures (categories and articles in com content), resulting in things like double content, confusing breadcrumbs etc.

Dne 5. mar. 2010 17:32 je ssnobben <ssno...@hotmail.com> napisal: