Adding MVC-like templating in plugin for Joomla! 1.5 and upwards

[JoomlaWorks]

I'd like to raise this issue, as it seems plugin templating was
somewhat neglected when J1.5 was released.

It is easy to add the functionality in J1.5 so that we can support MVC
like templating for plugins. We've taken this approach with 2 of our
plugins so far, you can check out the free Disqus Comments plugin to
see how we do it: http://extensions.joomla.org/extensions/5259/details

The functions used in the plugin can easily be incorporated in the J!
API.

Let me know if you're interested.

Regards,

Fotis
JoomlaWorks

[Andrew Eddie]

Hi Fotis and thanks for joining in.

Can you outline the principles, the theory that you are applying
(attach some example code if you like or place it inline)?

Actually, what I generally do with, for example, commenting plugins is
allow them to actually draw in a module (which is designed to be a
presentation element) so that they can be styled. This keeps the
plugin fairly light and not duplicating effort.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer



2009/6/30 JoomlaWorks <jooml...@gmail.com>:

[Angie Radtke]

Hi Fotis,

this idea sounds great, many times I changed the pagebreak -plugin in the
core .-)

Bye Angie




ausdrucks | STARK
Büro für Kommunikation Angie Radtke
www.der-auftritt.de
Witterschlicker Allee 52 53125 Bonn
0228/6420467 Mail:a.ra...@derauftritt.de
-----------------------------------------------------------------------
Barrierefreies Webdesign
von Angie Radtke und Dr. Michael Charlier
ISBN: 3-8273-2379-7

[JoomlaWorks]

The following code example refers to a content plugin which processes
the output of the article text.

Say the article output (as a string) is $article->text.

And say that we wanna wrap this with a div tag. Normally, I would do
this in the end of the plugin:

$article->text = '<div class="wrappingClass">'.$article->text.'</
div>';

Say I wanted to have the html on an external file like we do with
components and modules.
That means, I'd need to have a file called e.g. default.php containing
this:

<?php
// no direct access
defined( '_JEXEC' ) or die( 'Restricted access' );
?>
<div class="wrappingClass">
<?php echo $article->text; ?>
</div>

In order to replace $article->text in the plugin with my output based
on the above template file, all i have to do is create a function to
fetch the template file from the right directory (e.g. from the plugin
folders or the template folder):

// Path overrides
function getTemplatePath($pluginName,$file){
global $mainframe;
if(file_exists(JPATH_SITE.DS.'templates'.DS.$mainframe->getTemplate
().DS.'html'.DS.$pluginName.DS.str_replace('/',DS,$file))){
$p = JPATH_SITE.DS.'templates'.DS.$mainframe->getTemplate
().DS.'html'.DS.$pluginName.DS.$file;
} else {
$p = JPATH_SITE.DS.'plugins'.DS.'content'.DS.
$pluginName.DS.'tmpl'.DS.$file;
}
return $p;
}

where:
$pluginName is the name of the plugin and the folder name used within /
templates/myjoomlatemplate/html/ for the overrides
$file is the name of the template file (default.php, in our case).

So, we include the above function in some helper class (or the J API)
and call this within our plugin file.
The output would be something like this:

// Fetch the template
ob_start();
$myTemplate = getTemplatePath('my_plugin','default.php');
include($myTemplate);
$pluginOutput = ob_get_contents();
ob_end_clean();
// Output
$article->text = $pluginOutput;

We obviously need to follow some conventions, e.g. we create a folder
for our plugin with the plugin's name, on the same level with our
plugin files. In this new folder we create a subfolder called 'tmpl'
and in there we place our template files. The plugin name must also be
used for the folder we create within our /html/ folder in our template
so the overrides work.

[Amy Stephen]

Your example made me realize this might not be as helpful as I original hoped. Most plugins are very different from components or modules in that the logic tends to change the document, not put out a new section of content.

It's easy enough to create an included file that handles the final document replacement, but what does that really buy us? 

Plugins can have a series of regex commands, arrays with the results, and loops to process that content multiple times. To do it right, you'd have to create a model for each loop - and a layout - but  do we really want to make plugins that complex? I'm thinking of Smileys, or slimbox, or no follow on external links.

I like your idea of being able to separate the output so that there is an easy way to modify it without hacking the code -- in lots of cases, tho, I don't think a lot of optional markup is going on in there.

I see what Andrew's getting at when he raises the suggestion of the Module. Maybe where output is significant - a new section of information is appended - a Module should be used. Then, we have our model and layout in place, and overrides.

It's really a good question and I appreciate you raising this. As people get more sophisticated with Joomla! - these are the topics to consider.

[Andrew Eddie]

I think for that simplified case, you need to support the required
variation in the plugin params.

I think for more complex cases like the TOC in an article, we need to
redesign that a different way (not use a plugin). I'll have a go at
that Thursday for Friday.

Regardless though, there is nothing stopping you from using your
approach on a per-plugin basis. The API has more than enough hooks to
support it - but I haven't decided whether I'd encourage that
approach. There's a line where the plugin is really doing too much
and either you need to think about using a module or even extended
JHtml helpers.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/7/1 JoomlaWorks <jooml...@gmail.com>:

[JoomlaWorks]

@AmyStephen you obviously don't get it

@AndrewEddie what I'm saying is: create and add a simple API function
to fetch the template file like you do already with the modules.

[Andrew Eddie]

2009/7/1 JoomlaWorks <jooml...@gmail.com>:

>
> @AndrewEddie what I'm saying is: create and add a simple API function
> to fetch the template file like you do already with the modules.

Just use JPath::find in your plugin if you really want to support the
equivalent of layout overrides for plugins. However, since
presentation affecting plugins are only a small subset of the plugin
functionality (and arguable at that), I don't think it warrants
special treatment - that's just my opinion.

[Amy Stephen]

On Wed, Jul 1, 2009 at 5:37 AM, JoomlaWorks <jooml...@gmail.com> wrote:

@AmyStephen you obviously don't get it

I think I get it? The concepts you presented are really quite simple. I just don't agree that turning a Plugin into a Module is a good idea architecturally.

Here's how to load Module Parameters and fire it from a Plugin:

$module    = JModuleHelper::getModule('mod_tamka_comments_post');
$module->params    = "layout=form\narticleid=".$article->id;
$output .= $moduleRenderer->render($module, 'raw');
$article->text .= $output;

When we use that approach, template overrides are available. It's pretty slick.

Thanks.
Amy :)

 

[G. D. Speer]

@JoomlaWorks -
Perhaps you can work on your professionalism here. If the audience doesn't
understand something,
that's usually a failure of the presentor to communicate effectively, not of
the listener's aptitude.

Please try to be more respectful in your tone.

----- Original Message -----
From: "JoomlaWorks" <jooml...@gmail.com>
To: "Joomla! CMS Development" <joomla-...@googlegroups.com>
Sent: Wednesday, July 01, 2009 4:37 AM
Subject: Re: Adding MVC-like templating in plugin for Joomla! 1.5 and
upwards


>

> @AmyStephen you obviously don't get it
>
> @AndrewEddie what I'm saying is: create and add a simple API function
> to fetch the template file like you do already with the modules.
>

--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.13.1/2212 - Release Date: 07/01/09
05:53:00

[Robert Deutz]

Hi,

I think if you separate controlling, data handling and output in
components and modules it is not a good idea going an other way for
plugins. Same solution for the same problem. This makes it easier for
people to learn how it works.

@Andrew Yes, devs can do magic things, but why we can it make as easy
as possible?

@Amy I don't get. You are talking about modules and importing
parameters via a plugin. Is this topic really related to this
diskussion?

Form a practically view I know how many times we have copied a plugin
change it a little bit and used the changed plugin. If we can use
overwrites we have less pain.

Cheers,
Robert

On 1 Jul., 14:47, Amy Stephen <amystep...@gmail.com> wrote:

[JoomlaWorks]

@AmyStephen
Why load a module when you only have need to code a plugin?

@GD Speer

"If the audience doesn't understand something, that's usually a
failure of the presentor to communicate effectively, not of the
listener's aptitude. "

Really? If you visit a molecular biology website and don't understand
a thing it does not mean the people who run the site are
unprofessional or lack communication skills. ;)

My point is this: comment on something when you understand it. If you
don't, you'll only look like a fool.



All in all, I can understand there is no intention of adding new
features in the
code...

[Amy Stephen]

On Wed, Jul 1, 2009 at 9:10 AM, Robert Deutz <rde...@googlemail.com> wrote:

Hi,

I think if you separate controlling, data handling and output in
components and modules it is not a good idea going an other way for
plugins. Same solution for the same problem. This makes it easier for
people to learn how it works.

@Andrew Yes, devs can do magic things, but why we can it make as easy
as possible?

@Amy I don't get. You are talking about modules and importing
parameters via a plugin. Is this topic really related to this
diskussion?

Yes, Robert, I have found the same challenge in my development that Fotis is raising. The code I shared is from the Tamka comments extension.

Comments are a good example of this challenge. After an Article is presented, you want to possibly display several types of information - a "# of comments", a form to enter a new comment, and a list of the comments already made on the topic.

So, a content plugin is the needed to trap the logic flow. My comments plugin runs in onAfterDisplayContent and it then can access the &article object - retrieve the key - use that value to find associated comments, etc.

The problem is a plugin is not an ideal means of outputting a series of comments - that's work better suited for a Module - which has a model and a layout for this type of processing. The Module has all that good stuff you want to display content - and - as an added bonus for this question - you can also take full advantage of the Template overrides.

For that reason, I have an accompanying Module that I run from the Plugin -- using that code I shared with Fotis to show how to fire the Module and receive the Module output. That output can be added to the document so it displays exactly where you need it.

Pretty slick.  Does that help? It wasn't an obvious solution to me, either. Ian pointed out these possibilities to me when I was trying to figure out how to output content from the plugin in a reasonable way.

Form a practically view I know how many times we have copied a plugin
change it a little bit and used the changed plugin. If we can use
overwrites we have less pain.

Do you have examples of this? That might help when considering approaches. Plugins are used in so many different ways, maybe you are on to something.
 

Cheers,
Robert

Thanks Robert.
 

[Amy Stephen]

On Wed, Jul 1, 2009 at 9:19 AM, JoomlaWorks <jooml...@gmail.com> wrote:

@AmyStephen
Why load a module when you only have need to code a plugin?

I think that's a good question and one that I don't have enough knowledge to answer. I suppose it has to do with the application design pattern that is used by the Plugin and by the Module and simply using the right tools for the task at hand.

Fotis - I apologize for answering. I should have allowed Andrew to answer you. I was interested in your topic and your comments made me think. I acted impulsively, as I tend to do. I'll be more careful to just read and allow you to interact with Andrew, without interference.

You are pushing Joomla! in good ways. Keep up the great work.
Amy :)

 

[Andrew Eddie]

2009/7/2 Robert Deutz <rde...@googlemail.com>:

>
> Hi,
>
> I think if you separate controlling, data handling and output in
> components and modules it is not a good idea going an other way for
> plugins. Same solution for the same problem. This makes it easier for
> people to learn how it works.
>
> @Andrew Yes, devs can do magic things, but why we can it make as easy
> as possible?

How much easier do you want? JPath::find is what the whole layout
override system uses.

The point here is that the plugin system is more that presentation.
It's got SEF router handlers, it's got authentication plugins, etc and
so on. They are things that react to events in the execution of
Joomla. Their primary job is not presentation - that is merely a very
small subset.

Adding complex presentation elements can be done a number of ways but
adding a layout override system for "all" plugins is over-designing in
my opinion (what use has a Twitter authentication plugin for layout
overrides). The elements for adding that support for you own plugin
though are already there - just do it - nobody is stopping you and
it's drop-dead simple.

$paths = array();
$path[] = dirname(__FILE__).DS.'tmpl';
$path[] = JPATH_SITE.DS.'templates'.DS.$app->getTemplate()
.DS.'html'.DS.'plg_foobar';
if ($layout = JPath::find($paths, $this->params->get('layout',
'default').'.php')) {
include $layout;
}

Six or seven lines of code!

So this is technically achievable using the existing blocks in the
API. This is not difficult for someone of your or Fotis's calibre to
grasp.

Secondly though, is this actually a good idea? I'd err on the side of
no. I've already pointed out the page TOC builder is the wrong way to
do it (in hindsight, and since I wrote that originally I can blame
myself). I've also pointed out that it's possible to allow plugins to
bring in modules which are things that are actually designed for
presentation work.

You have a lot of choice already to do this.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer


>

[Andrew Eddie]

2009/7/2 JoomlaWorks <jooml...@gmail.com>:
>
> @all

> I can understand there is no intention of adding new features in the
> code.

Absolutely - especially when they already exist :)

See my reply to Robert. If you are able to produce an extension of
the magnitude of K2, then you are certainly able to include those six
or seven lines of code in the plugins where you need them ;) The
support is already there and at least two code examples have been
cited - just use it.

I cannot make this clear enough. The Joomla core is not stopping you
from doing this. You can achieve this in 1.5 today if you want. What
you need to understand though, is plugins don't just do presentation
work. Hence if you want them to do the job of a module or component,
either you shift the functionality to those extensions, or you add a
small layer to support it. It's really not a big deal, is it? That's
how I would do and have done it.

But just as an aside, in your example you use global $mainframe. The
better "1.5" way of doing that is:

$mainframe = &JFactory::getApplication();

or we tend to use this format in the code now:

$app = &JFactory::getApplication();

The global $mainframe variable is deprecated in 1.5 and removed in 1.6
so best to have your extensions using that format. For more little
bits and pieces like that, see my cheat sheet:
http://www.theartofjoomla.com/converting-old-extensions.html All that
does is notate what the legacy plugin does - it's not rocket science,
fortunately.

This is also a good time to remind, again, all devs legacy mode is NOT
available in 1.6. The API is backward compatible where possible but
there is no legacy mode. The 1.5 legacy mode was only intended to
bridge the gap between the major changes from 1.0 to 1.5. If you are
running your extensions on the native 1.5 API (and I mean native), you
are "1.6 ready" in the sense that only minor changes are required for
you to adjust to the new ACL, nested-set (menus and categories) and
PHP requirements (unfortunately there are parts of the menus,
categories and ACL systems that are just impossible to provide with
100% backward compatibility). If you want to discuss the implications
of this further, please open up a new thread on this list. It's
better to speak up early and be a part of the development process than
be caught unawares when 1.6 stable arrives.

[Robert Deutz]

Hi,

first it is not true that a plugin don't have a presentation part.
Most of the Content-Plugins have.

Second, I can write this six lines of code, but can a template
designer do this, should he do this? I think he doesn't.

Third, use the same strategie for the same problem, is have said this
already. I go a little bit more in detail to explain what I exactly
mean.

The Joomla! Framework is a pattern based framework, that use a named
based schema to find files. For a component e.g. com_xyz you have a
directory com_xyz and in this directory a file xyz.php that is
included, if someone call index.php?option=com_xyz. That is clear and
easy. For components and modules we use to implement the functionality
a MVC design. I won't go to much in detail here, but I'd like to say
it is our software design principle.

If we talk about plugins it is a little bit different. Plugin were
fired on events, so it possible that a plugin is executed many times
on different steps in application workflow. But this is only how we
execute a plugin at the end a plugin implements a functionality. And
here the circle is closing. It is functionality and we have a
software design principle, we use a MVC pattern.

Components, Moduls and Plugin are the same, they implement
functionality. I came back to my third point: use the same strategie
for the same problem.
q.e.d.

Beside this theoretical reasons for using MVC, I'd like to give some
examples:

On some Website we made we use the pagination or the pagebreak but the
output is not so we need it. And the end we have two possibilities:
1) Change the core
2) Make a new plugin, disable the old

We can't do 1) this breaks our major Rule "DO NOT HACK THE CORE"
So we need to do 2) and must do this only because the output don't
fits our needs. This is needless.

Andrew you say that is oversized, yes I agree partially. I try to take
the problem from the other site. We force nobody to use MVC for
programming components or modules, but we allow this! We have made the
design so that anyone can use MVC patterns. On Framework level we have
implement this, I see no reason that we don't do the same for plugins.
It is a little bit work but I am sure we will find people to make this
happen.


Cheers,
Robert


On 2 Jul., 00:15, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/7/2 JoomlaWorks <joomlawo...@gmail.com>:

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
>

[Louis Landry]

Hi Robert,

On Thu, Jul 2, 2009 at 3:24 AM, Robert Deutz <rde...@googlemail.com> wrote:

Hi,

first it is not true that a plugin don't have a presentation part.
Most of the Content-Plugins have.

Firstly, content plugins make up a small part of the plugins and events that are available with Joomla.  There are currently 5 content plugins in the trunk I believe, and around 25 non-content plugins.

Secondly, the only reason that most of those plugins exist is because we didn't get to dealing with them during the 1.5 release cycle.  It was always the intention to move most of them right into com_content.  Content plugins like "pagenavigation" and "pagebreak" and "vote" are really constructs of com_content and belong there, not in an abstract content plugin.

Thirdly, architecturally, plugins are not designed to just render output.  They exist to manipulate the application state and control flow during runtime.  Certainly they can be used for all sorts of things -- one of which would be to render some output directly -- but that does not mean it is the best way to handle it.

 

Second, I can write this six lines of code, but can a template
designer do this, should he do this? I think he doesn't.

A template designer wouldn't be writing that code, the person writing the plugin would.  A template designer would simply be putting a layout in an appropriate folder specified by the plugin author.

 

Third, use the same strategie for the same problem, is have said this
already. I go a little bit more in detail to explain what I exactly
mean.

The Joomla! Framework is a pattern based framework, that use a named
based schema to find files. For a component e.g. com_xyz you have a
directory com_xyz and in this directory a file xyz.php that is
included, if someone call index.php?option=com_xyz. That is clear and
easy. For components and modules we use to implement the functionality
a MVC design. I won't go to much in detail here, but I'd like to say
it is our software design principle.

If we talk about plugins it is a little bit different. Plugin were
fired on events, so it possible that a plugin is executed many times
on different steps in application workflow. But this is only how we
execute a plugin at the end a plugin implements a functionality. And
here    the circle is closing. It is functionality and we have a
software design principle, we use a MVC pattern.

MVC is not a software design principle it is a design pattern, and actually the MVC pattern is only used for components.

There is a convention for calling a JModuleHelper::getLayoutPath() method which in turn tells you what file to include: either yours or one made available by a template developer.  There is no controller for the module by convention nor is there really a model.  Obviously modules can load models from components, or optionally they *could* have their own, but the latter certainly isn't a convention we have made nor is it one that we have promoted.

 

Plugins are very different from modules and plugins both in design and concept.  Of course they "implement a functionality", so does a library or really anything.  That doesn't mean that it should have a layout override designed for it.

Components, Moduls and Plugin are the same, they implement
functionality. I came back to my third point: use the same strategie
for the same problem.
q.e.d.

I'm sorry, but that q.e.d. is anything but.  They are by no means the same.  JArrayHelper implements a functionality too, but it isn't the same as a Component, Module, or Plugin either.  It is not the same problem.  You may be trying to solve the same problem with plugins, but that doesn't mean that it is the correct or best way to solve the problem.

 

Beside this theoretical reasons for using MVC, I'd like to give some
examples:

On some Website we made we use the pagination or the pagebreak but the
output is not so we need it. And the end we have two possibilities:
1) Change the core
2) Make a new plugin, disable the old

We can't do 1) this breaks our major Rule "DO NOT HACK THE CORE"
So we need to do 2) and must do this only because the output don't
fits our needs. This is needless.

See my point above.  You *could* have new pagination or pagebreak plugins that *do* output  what you want them to output.  You don't have to hack the core at all, just replace the plugins, option 3.  I am sorry we didn't get to those particular ones during the 1.5 cycle, it would have been a better release for it.

Andrew you say that is oversized, yes I agree partially. I try to take
the problem from the other site. We force nobody to use MVC for
programming components or modules, but we allow this! We have made the
design so that anyone can use MVC patterns. On Framework level we have
implement this, I see no reason that we don't do the same for plugins.
It is a little bit work but I am sure we will find people to make this
happen.

The work isn't what is in question, the rationale and purpose is.  As for what is forced or allowed, there is nothing stopping you from having the functionality that you want, Andrew gave you a very small number of lines of code to solve the problem if you want to do that.  That doesn't mean that we should promote an architectural pattern that is possible, but goes against the design goals of the system we built.

- Louis 

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[Robert Deutz]

Hi Louis,

On 2 Jul., 11:02, Louis Landry <louis.lan...@joomla.org> wrote:
> Hi Robert,
>
> On Thu, Jul 2, 2009 at 3:24 AM, Robert Deutz <rde...@googlemail.com> wrote:
>
> > Hi,
>
> > first it is not true that a plugin don't have a presentation part.
> > Most of the Content-Plugins have.
>
> Firstly, content plugins make up a small part of the plugins and events that
> are available with Joomla.  There are currently 5 content plugins in the
> trunk I believe, and around 25 non-content plugins.
>
> Secondly, the only reason that most of those plugins exist is because we
> didn't get to dealing with them during the 1.5 release cycle.  It was always
> the intention to move most of them right into com_content.  Content plugins
> like "pagenavigation" and "pagebreak" and "vote" are really constructs of
> com_content and belong there, not in an abstract content plugin.
>
> Thirdly, architecturally, plugins are not designed to just render output.
>  They exist to manipulate the application state and control flow during
> runtime.  Certainly they can be used for all sorts of things -- one of which
> would be to render some output directly -- but that does not mean it is the
> best way to handle it.
>

What we are talking about, if we talk about the present or the future.
Atm plugins render output, no question. 1.6 goes the same way

>
>
> > Second, I can write this six lines of code, but can a template
> > designer do this, should he do this? I think he doesn't.
>
> A template designer wouldn't be writing that code, the person writing the
> plugin would.  A template designer would simply be putting a layout in an
> appropriate folder specified by the plugin author.

And the content plugins that render code atm don't allow this or don't
go the way you have show.

>
> > Third, use the same strategie for the same problem, is have said this
> > already. I go a little bit more in detail to explain what I exactly
> > mean.
>
> > The Joomla! Framework is a pattern based framework, that use a named
> > based schema to find files. For a component e.g. com_xyz you have a
> > directory com_xyz and in this directory a file xyz.php that is
> > included, if someone call index.php?option=com_xyz. That is clear and
> > easy. For components and modules we use to implement the functionality
> > a MVC design. I won't go to much in detail here, but I'd like to say
> > it is our software design principle.
>
> > If we talk about plugins it is a little bit different. Plugin were
> > fired on events, so it possible that a plugin is executed many times
> > on different steps in application workflow. But this is only how we
> > execute a plugin at the end a plugin implements a functionality. And
> > here    the circle is closing. It is functionality and we have a
> > software design principle, we use a MVC pattern.
>
> MVC is not a software design principle it is a design pattern, and actually
> the MVC pattern is only used for components.

It is our principle to use mvc for implementing functionality.

>
> There is a convention for calling a JModuleHelper::getLayoutPath() method
> which in turn tells you what file to include: either yours or one made
> available by a template developer.

Why not have a JPluginHelper::getLayoutPath() method ?

>  There is no controller for the module by
> convention nor is there really a model.  Obviously modules can load models
> from components, or optionally they *could* have their own, but the latter
> certainly isn't a convention we have made nor is it one that we have
> promoted.
> Plugins are very different from modules and plugins both in design and
> concept.  Of course they "implement a functionality", so does a library or
> really anything.  That doesn't mean that it should have a layout override
> designed for it.
>
> Components, Moduls and Plugin are the same, they implement
>
> > functionality. I came back to my third point: use the same strategie
> > for the same problem.
> > q.e.d.
>
> I'm sorry, but that q.e.d. is anything but.  They are by no means the same.
>  JArrayHelper implements a functionality too, but it isn't the same as a
> Component, Module, or Plugin either.  It is not the same problem.  You may
> be trying to solve the same problem with plugins, but that doesn't mean that
> it is the correct or best way to solve the problem.
>

Sorry Louis, but I don't get it why there is so many resistance.
It hurts nobody but it makes it easier for all.

I disagree, I (we) request
* for a additional function in JPluginHelper
* for a move of some files in subfolders
* and for a little bit refractoring of content-plugins
thats all.

If this is against the design goals of the system, it's time to think
about the design goals.

I don't know if my next sentence are politely and kindly enough. It is
not against you or anyone personally.

It seems to me that the core developers are very resistant again new
ideas those are a liitle bit besides there view. For me it is to much
fighting for such a little add on. Community involvement makes only
sence if this results in new or better things.

It is a little bit out of scope, but I have looked at the Feature
Tracker (order by prio) the first 5 pages 90% of the items are
untouched. Last modification date == open date. This annoyed people
and I know many people that are willing to help but the stand on the
floor calling "I will help" all doors are open but nobody like to
speak with them.

Kindly Regards,
Robert

> >http://www.theartofjoomla.com/converting-old-extensions.htmlAll that

> > > does is notate what the legacy plugin does - it's not rocket science,
> > > fortunately.
>
> > > This is also a good time to remind, again, all devs legacy mode is NOT
> > > available in 1.6.  The API is backward compatible where possible but
> > > there is no legacy mode.  The 1.5 legacy mode was only intended to
> > > bridge the gap between the major changes from 1.0 to 1.5.  If you are
> > > running your extensions on the native 1.5 API (and I mean native), you
> > > are "1.6 ready" in the sense that only minor changes are required for
> > > you to adjust to the new ACL, nested-set (menus and categories) and
> > > PHP requirements (unfortunately there are parts of the menus,
> > > categories and ACL systems that are just impossible to provide with
> > > 100% backward compatibility).  If you want to discuss the implications
> > > of this further, please open up a new thread on this list.  It's
> > > better to speak up early and be a part of the development process than
> > > be caught unawares when 1.6 stable arrives.
>
> > > Regards,

> > > Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla

[Angie Radtke]

Hi together,
I'm not a progammer, but for me it sounds very comfortable to get a
possibility to change the plugin output.

Last year I made a side for a photographer . I built an image gallery with
Joomla on-board means.
The pagebreak-plugin was very helpful for this.
You can see the result :
http://www.benfn.de/index.php?option=com_content&view=article&id=147:couple-of-women&catid=6:frauen&Itemid=20

( the numbers below the big picture)

Bye Angie


ausdrucks | STARK
Büro für Kommunikation Angie Radtke
www.der-auftritt.de
Witterschlicker Allee 52 53125 Bonn
0228/6420467 Mail:a.ra...@derauftritt.de
-----------------------------------------------------------------------
Barrierefreies Webdesign
von Angie Radtke und Dr. Michael Charlier
ISBN: 3-8273-2379-7

----- Original Message -----
From: "Robert Deutz" <rde...@googlemail.com>
To: "Joomla! CMS Development" <joomla-...@googlegroups.com>
Sent: Thursday, July 02, 2009 12:36 PM
Subject: Re: Adding MVC-like templating in plugin for Joomla! 1.5 and
upwards

[Andrew Eddie]

Robert, can you please provide me with several real world examples
rather than playing around with hypotheticals. There is obviously a
disconnect here between what you think we are saying and what we think
you want. Fotis, same for you unless you are both looking at the same
issues which it sort of sounds like it.

That said, I can't add anything to what Louis covered. You *can* use
MVC in a plugin if you want. Do I think it's a good design idea - no.
Does that equate to resistance - no. Let's be a little bit sensible
here, eh? Show me some good proofs of concept that demonstrate that
it's needed and we'll pull the ideas apart. Things can move quickly
(just check today's commit logs), but even I am subject to scrutiny
and for everything that I commit there are probably 100 ideas already
shot down by my peers (case in point, I was going to refactor tp=1 the
wrong way - the community helped tune that for a better outcome).

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/7/2 Robert Deutz <rde...@googlemail.com>:

[Andrew Eddie]

What am I looking at or for Angie?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer


2009/7/2 Angie Radtke <a.ra...@derauftritt.de>:

[Robert Deutz]

Hi Andrew,

On 2 Jul., 13:00, Andrew Eddie <mambob...@gmail.com> wrote:
> Robert, can you please provide me with several real world examples
> rather than playing around with hypotheticals.  There is obviously a
> disconnect here between what you think we are saying and what we think
> you want.  Fotis, same for you unless you are both looking at the same
> issues which it sort of sounds like it.

1) Angie's images gallery example would work only with overwrites
2) TOC it is a table but on an accessilble site a list is better
3) Pagenavigation also a table, but a list is better
4) the superblogger plugin Fotis has made
5) ...

you need more, no problem but this takes a lot more explanatory notes
to understand what this specific plugin does.

>
> That said, I can't add anything to what Louis covered.  You *can* use
> MVC in a plugin if you want.  Do I think it's a good design idea - no.
>  Does that equate to resistance - no.  Let's be a little bit sensible
> here, eh?  

Of course, it is not my intention to judge someone.


Cheers,
Robert

>Show me some good proofs of concept that demonstrate that
> it's needed and we'll pull the ideas apart.  Things can move quickly
> (just check today's commit logs), but even I am subject to scrutiny
> and for everything that I commit there are probably 100 ideas already
> shot down by my peers (case in point, I was going to refactor tp=1 the
> wrong way - the community helped tune that for a better outcome).
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

> ...
>
> Erfahren Sie mehr »

[JoomlaWorks]

On Jul 2, 2:00 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> Let's be a little bit sensible

> here, eh? Show me some good proofs of concept that demonstrate that

> it's needed and we'll pull the ideas apart.

> 2009/7/2 Robert Deutz <rde...@googlemail.com>:

We recently launched SuperBlogger, a content plugin which
significantly changes the output of the article in both listings and
article pages: http://www.joomlaworks.gr/content/view/56/42/

As you can see on the demo http://dev.joomlaworks.gr/plugins/new-jw-blogging-plugin-running-in-this-article.html
the amount of HTML used could not have stayed outside some MVC
approach, otherwise it would be a nightmare to reposition objects. To
take this approach one step further, we can actually use content
plugins to create our own template modifications in the article text
output (e.g. separate dynamically the introtext from fulltext) and not
only, so we can apply different layouts on the fly, without actually
changing the tons of templates used by com_content.

I can provide Andy and Louis with a copy of SuperBlogger if you want,
so you can see what I mean. If you wanna see what SuperBlogger does
but in a smaller scale, you can check out our free Disqus plugin,
which uses the same approach, using 2 templates for modifying the
article output in listing and article pages.
http://extensions.joomla.org/extensions/5259/details

I will have to agree with Robert so far. The amount of resistance put
in this post is way to much that just creating a 6-7 line
JPluginHelper::getLayoutPath() method in the core. I mean, you could
just come back with "done" or "included" and not explaining to me the
purpose of plugins in Joomla!. I know what their purpose is and I
think you can do lots of magic things with them. And not only on the
"onPrepareContent" event but on all other 5-6 events available
(before, after title etc.). If there is a need for HTML output, there
is a need for an MVC-like approach.

For the record, I'm not just producing extensions for Joomla! with my
team. I also run a company building some very complex and high traffic
websites with Joomla! - this is how K2 came to be, actually, it was
something we needed for many reasons, from styling, to features, to
better performance etc.

[Andrew Eddie]

2009/7/2 Robert Deutz <rde...@googlemail.com>:
>

> Hi Andrew,
>
>
> On 2 Jul., 13:00, Andrew Eddie <mambob...@gmail.com> wrote:
>> Robert, can you please provide me with several real world examples
>> rather than playing around with hypotheticals.  There is obviously a
>> disconnect here between what you think we are saying and what we think
>> you want.  Fotis, same for you unless you are both looking at the same
>> issues which it sort of sounds like it.
>
>
> 1) Angie's images gallery example would work  only  with overwrites

Going to move the TOC to a view layout (where it belongs). The
solution is not to MVC the plugin. The solution is to put the output
where it belongs.

> 2) TOC it is a table but on an accessilble site a list is better

See #1

> 3)  Pagenavigation also a table, but a list is better

Agree totally. Probably will change the default to use that. The
legacy layout overrides can contain the old table layout.

> 4) the superblogger plugin Fotis has made

I suggest he looks at how we do comments when it's committed. It's
quite smart and drop-dead easy for the designer to customise.

> 5) ...

That's a hard one to solve :P

> you need more, no problem but this takes a lot more explanatory notes
> to understand what this specific plugin does.

The goal is that you want more flexibility for designers. Hey, that's
my goal to :) And part of that is to fix the right problem. MVC-ing
plugins is not solving the correct problem, particularly in the case
of the page TOC maker. The problem is that some core plugins haven't
evolved the correct way.

Just trust me on this one ;) I think you'll be happy with the result.
I just need to work through some nested-set issues first.

Regards,
Andrew Eddie

[Robert Deutz]

Hi Andrew,

forget MVC, call it flexible output rendering. If the term MVC is the
problem delete it. I don't care.


Cheers,
Robert

> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer

>
>
>
> >> That said, I can't add anything to what Louis covered.  You *can* use
> >> MVC in a plugin if you want.  Do I think it's a good design idea - no.
> >>  Does that equate to resistance - no.  Let's be a little bit sensible
> >> here, eh?
>
> > Of course, it is not my intention to judge someone.
>
> > Cheers,
> > Robert
>
> >>Show me some good proofs of concept that demonstrate that
> >> it's needed and we'll pull the ideas apart.  Things can move quickly
> >> (just check today's commit logs), but even I am subject to scrutiny
> >> and for everything that I commit there are probably 100 ideas already
> >> shot down by my peers (case in point, I was going to refactor tp=1 the
> >> wrong way - the community helped tune that for a better outcome).
>
> >> Regards,

> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer

> ...
>
> Erfahren Sie mehr »

[Andrew Eddie]

I'm happy to take a look.

And there's no resistance. Not a day goes by that I don't throw up a
crazy idea that gets shot down, probably for good reason. I know you
think this is tedious and don't like long discussions - let me tell
you a secret, neither do I. But you have to admit there is a balance.

I know what your problem is - I hit it well over a year ago. The
approach I took was to use modules (even the ajax output runs through
the module so it's one place to customise) or JHtml helpers, or other
things directly connected with the output system. I'm more than happy
to look at your approach and see if there are things that can be
learned. But everyone also has the right to ask "why are you doing it
that way because it sounds odd" or "can I suggest a better way"?
Fair?

To date, if you look at the trunk, the trend is to make it easier on
the poor old designer to customise their work. The markup is rough,
but it's there. I certainly don't wake up in the morning and wonder
how insanely difficult I can make Joomla today. That's a tad
unrealistic.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/7/2 JoomlaWorks <jooml...@gmail.com>:

[JoomlaWorks]

What I, Robert and more are saying/thinking is this: if you provide an
MVC pattern for components and modules, do it for plugins as well.

It would be a warm community welcome to see new features getting added
in 1.5, now.

You've included comments in 1.6.
I guess they were considered overkill in 1.5.
What has changed since then?
See my point?

[JoomlaWorks]

One more thing... MVC templating should not be used for html templates
only, but for CSS as well - in my opinion. If you provide the means to
override HTML, provide the means to override CSS and JS files as well.
Just because Joomla! core modules and plugins don't use CSS or JS,
doesn't mean all Joomla! extensions don't too.

[Andrew Eddie]

Ok, here's the deal.

Watch how com_content unfolds over the coming weeks. If you like what
you see, great. If you don't, let's pull it apart.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/7/2 JoomlaWorks <jooml...@gmail.com>:
>

[Andrew Eddie]

That's what

JHtml::stylesheet and JHtml::script are for. Have a look at any of my
freebie extensions - I do that all the time. You stick those in the
layouts so the designer can override them. Simple :D

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/7/2 JoomlaWorks <jooml...@gmail.com>:
>

[Louis Landry]

Hi Robert,

On Thu, Jul 2, 2009 at 5:36 AM, Robert Deutz <rde...@googlemail.com> wrote:

Hi Louis,

On 2 Jul., 11:02, Louis Landry <louis.lan...@joomla.org> wrote:
> Hi Robert,
>

> On Thu, Jul 2, 2009 at 3:24 AM, Robert Deutz <rde...@googlemail.com> wrote:
>
> > Hi,
>
> > first it is not true that a plugin don't have a presentation part.
> > Most of the Content-Plugins have.
>
> Firstly, content plugins make up a small part of the plugins and events that
> are available with Joomla.  There are currently 5 content plugins in the
> trunk I believe, and around 25 non-content plugins.
>
> Secondly, the only reason that most of those plugins exist is because we
> didn't get to dealing with them during the 1.5 release cycle.  It was always
> the intention to move most of them right into com_content.  Content plugins
> like "pagenavigation" and "pagebreak" and "vote" are really constructs of
> com_content and belong there, not in an abstract content plugin.
>
> Thirdly, architecturally, plugins are not designed to just render output.
>  They exist to manipulate the application state and control flow during
> runtime.  Certainly they can be used for all sorts of things -- one of which
> would be to render some output directly -- but that does not mean it is the
> best way to handle it.
>

What we are talking about, if we talk about the present or the future.
Atm plugins render output, no question. 1.6 goes the same way

Just because something is done wrong doesn't mean you continue to do it wrong and use that as an excuse to do other things wrong like it.

 

>
>
> > Second, I can write this six lines of code, but can a template
> > designer do this, should he do this? I think he doesn't.
>
> A template designer wouldn't be writing that code, the person writing the
> plugin would.  A template designer would simply be putting a layout in an
> appropriate folder specified by the plugin author.

And the content plugins that render code atm don't allow this or don't
go the way you have show.

Write a patch to fix them to allow it.  I bet it gets committed to trunk :) ... it might even get backported to 1.5, who knows.

 

>
> > Third, use the same strategie for the same problem, is have said this
> > already. I go a little bit more in detail to explain what I exactly
> > mean.
>
> > The Joomla! Framework is a pattern based framework, that use a named
> > based schema to find files. For a component e.g. com_xyz you have a
> > directory com_xyz and in this directory a file xyz.php that is
> > included, if someone call index.php?option=com_xyz. That is clear and
> > easy. For components and modules we use to implement the functionality
> > a MVC design. I won't go to much in detail here, but I'd like to say
> > it is our software design principle.
>
> > If we talk about plugins it is a little bit different. Plugin were
> > fired on events, so it possible that a plugin is executed many times
> > on different steps in application workflow. But this is only how we
> > execute a plugin at the end a plugin implements a functionality. And
> > here    the circle is closing. It is functionality and we have a
> > software design principle, we use a MVC pattern.
>
> MVC is not a software design principle it is a design pattern, and actually
> the MVC pattern is only used for components.

It is our principle to use mvc for implementing functionality.

Who is "our"?  It isn't the Joomla project's principle.  We have TONS of functionality that isn't implemented with the MVC pattern.  MVC isn't appropriate for everything.

 

>
> There is a convention for calling a JModuleHelper::getLayoutPath() method
> which in turn tells you what file to include: either yours or one made
> available by a template developer.

Why not have a JPluginHelper::getLayoutPath() method ?

For the reasons I have described.  Plugins aren't designed to render output, they can render modules and such, but inherently they are not designed to directly render output.  You don't need that method, as Andrew has shown earlier it can be done with only a few lines of code.

 

>  There is no controller for the module by
> convention nor is there really a model.  Obviously modules can load models
> from components, or optionally they *could* have their own, but the latter
> certainly isn't a convention we have made nor is it one that we have
> promoted.
> Plugins are very different from modules and plugins both in design and
> concept.  Of course they "implement a functionality", so does a library or
> really anything.  That doesn't mean that it should have a layout override
> designed for it.
>
> Components, Moduls and Plugin are the same, they implement
>
> > functionality. I came back to my third point: use the same strategie
> > for the same problem.
> > q.e.d.
>
> I'm sorry, but that q.e.d. is anything but.  They are by no means the same.
>  JArrayHelper implements a functionality too, but it isn't the same as a
> Component, Module, or Plugin either.  It is not the same problem.  You may
> be trying to solve the same problem with plugins, but that doesn't mean that
> it is the correct or best way to solve the problem.
>

Sorry Louis, but I don't get it why there is so many resistance.
It hurts nobody but it makes it easier for all.

I'm sorry you don't get it.  There is resistance because it is an incorrect solution to your problem.  If a couple of content plugins are out of place or are doing something wrong then they should be fixed to work correctly, not the system broken to work with the plugins.

I vehemently disagree with adding the layout method to JPluginHelper.  I am open to moving files around in subfolders, but you are not being specific to what that is.  I am all for refactoring content plugins and actually removing those two plugins that you mentioned.  That logic belongs in com_content directly.

I've been thinking about the design goals of the system for years now :-)

 

I don't know if my next sentence are politely and kindly enough. It is
not against you or anyone personally.

It seems to me that the core developers are very resistant again new
ideas those are a liitle bit besides there view. For me it is to much
fighting for such a little add on. Community involvement makes only
sence if this results in new or better things.

Then stop fighting :-) ... does it seem to you that the core devs are resistant to new ideas, or your new idea?  Every decision that is made about what goes in the core is scrutinized.  There are very few exceptions.  Well over half of my ideas didn't make it into the core, and that isn't necessarily a bad thing.  "Better" is subjective.  Just because you see something is better doesn't mean I think so, and vice versa.

 

It is a little bit out of scope, but I have looked at the Feature
Tracker (order by prio) the first 5 pages 90% of the items are
untouched. Last modification date == open date. This annoyed people
and I know many people that are willing to help but the stand on the
floor calling "I will help" all doors are open but nobody like to
speak with them.

Each one of them should post threads about their ideas and patches on this list so that they can be discussed.  Some of them will get shot down, some of them will get committed, and some of them will be reworked and committed.  

Cheers,

Louis

[Louis Landry]

What I am saying is this: Plugins are very distinctly different than modules and components.  Modules do not use an MVC pattern, but simply have a way to get a layout path from the template if it exists.

Comments wasn't considered overkill in 1.5, we just didn't have any code written for them and it wasn't high on our priority list of things to do.  If you, for example, had written a comments system at the time and offered it to us it is entirely possible that it would have been added to the core.  You didn't, it didn't.

- Louis

[JoomlaWorks]

Oh come on... we try to get you add a few lines of code in joomla and
we pass the spanish equisition. Imagine if I had offered to do so for
a "comments system". We'd be still talking about it... LOL

Ok, forget I asked in the first place.

Andrew has been more open on the matter and promised to do some
changes (i hope some mvc enabling code for plugins is added).

But Louis, you're just hiding behind your finger explaining this and
that and be negative. As a friendly advise, I'd recommend watching
Carrey's new movie "the yes man" for a change. ;)

On Jul 2, 9:23 pm, Louis Landry <louis.lan...@joomla.org> wrote:
> What I am saying is this: Plugins are very distinctly different than modules
> and components.  Modules do not use an MVC pattern, but simply have a way to
> get a layout path from the template if it exists.
> Comments wasn't considered overkill in 1.5, we just didn't have any code
> written for them and it wasn't high on our priority list of things to do.
>  If you, for example, had written a comments system at the time and offered
> it to us it is entirely possible that it would have been added to the core.
>  You didn't, it didn't.
>
> - Louis
>

[klas berlič]

People want to use  modules and components in the same way, there are numerous examples of this in extensions, separation is artificial and disturbing.

Functionalities of both should be merged into one powerfull extension type. Vertical capabilities of components (ability to accept parameters, MVC architecture ..) married with horizontal capabilities of modules (ability to run multiple instances + multitile different modules on the same page).

2009/7/3 JoomlaWorks <jooml...@gmail.com>

[Robert Deutz]

Hi Louis,

Is fighting really the correct word, I can stop talking about that
issue, no problem.
If you or "The Code Devs" don't like my ideas, I don't care. It is the
type of diskussion, how ideas and proposales are handled.

And btw. "Better" isn't subjective, in a technical subject area you
have pro and cons. How many importance one topic has is within limits
subjective, but this doesn't make it subjective at all.

>
> > It is a little bit out of scope, but I have looked at the Feature
> > Tracker (order by prio) the first 5 pages 90% of the items are
> > untouched. Last modification date == open date. This annoyed people
> > and I know many people that are willing to help but the stand on the
> > floor calling "I will help" all doors are open but nobody like to
> > speak with them.
>
> Each one of them should post threads about their ideas and patches on this
> list so that they can be discussed.  Some of them will get shot down, some
> of them will get committed, and some of them will be reworked and committed.

You are kidding, don't you? People add over more then two years
tracker items, nearly nobody take a look at this suggestions and now
we should start by zero. How you will motivate people to put work in
posting the informations twice, if the first try was futile?


Cheers,
Robert

[Louis Landry]

@Fotis,

I've seen the movie, and its not that new.  You might remember at the end the moral of the story was that you don't have to say yes to everything or it may get you into trouble.

The point you seem to be missing that it isn't about how many lines of code.  There are reasons for things being designed the way they are, and just because you don't agree with them or don't understand them doesn't make them less valid.

You clearly don't really understand what MVC means because you and Robert both are continually referring to "MVCing " plugins and how modules already are.  I don't know what hiding behind my finger means, but I have tried to explain to you both how plugins are different.  You don't have to agree with me but it's not being negative, it's just disagreeing.

On the contrary, comparing a vigorous discussion about the merits of making a change to the framework API to the spanish inquisition isn't melodramatic or negative at all. :-)  As for the commenting system, I guess we'll never know because neither you or anyone else did offer.

@Robert,

I used the word fighting because you did.  I actually see it as a good and healthy debate, not a fight.  I learned long ago that I don't always get my way when debating things in the code base, but I still think that having the debates and discussions is great for teasing out the best solutions and better understanding of how things work or should work.

Better is absolutely subjective in this context.  We aren't talking about two identical inputs and outputs and which is faster or easier on memory.  We are talking about opinions of whether or not something belongs in the framework API.  In most cases "better" is subject to someone's perspective and understanding of the situation.

The development process two years ago has very little to do with the development process today.  I would know, I have been a major part in both.  It is regretful that patches have been either ignored or overlooked in the past.  If people don't want to try again I can understand that, and I can sympathize with their frustration.  All we can do now is learn from the past and work to improve the future.  That is what we are trying to do.  Just dwelling on the mistakes of the past won't get us very far after all.

Cheers,

Louis