Hello togehter,

are there any existing patterns or common use:

"how to extend com_content with aditional data either logics?"

i am working around that i want to use as much as i can,
from the nicely implemented core component. so i thought about
a own database class followed by a decorator or facade pattern.

what do you think?

greetz mario
*ilovejoomla*

Hi Boojam,

Welcome to the Joomla! development forums. You could indeed try to extend com_content using a decorator or/and facade pattern depends what you want to to. Maybe you could share you ideas about the kind of extensions our want to implement ?

Cheers,

Johan

Ok i got a lot of Ideas on of it is to go a for me usually way.

The Framework defines some events that may be obviously helpful,
p.e. onPrepareContent. So i could write a plugin that would modify/overwrite the
&row-reference passed to that plugin-method.
Like this:

Code: Select all

function MyOnPrepareContent( &$row, &$params, $page=0 ) {
   $row = MyDecoratorFactory::getPressDecorator (&$row);
}

ok thats nothing spectaculous. But here it goes on:

class PressDecorator implements IContentDecorator {

   protected $content
   [...]
   
   public function __construct(stdClass $content) {
      $this->content = $content;
   
   }
   
   //and here some delegators with interceptors
   
   public function __get($key) {
      return $this->content->$key;
      //or
      switch($key) {
         "title":
            return "Mr & Mrs.".$this->content->title; //or some thing like that ;-)
            break;
      }
   }
   
   //i know there a some troubles with it
   public function __set($key,$value) {
      $this->content->$key = $value;
   }
   
   public function __call($meth,$params) {
      [...and so on]
   }
   
   [...]

}


The Decorator/Facade pattern is one way to do it.
If you could imagine,that you put a second $item to it.
Like this

Code: Select all

public function loadPressContent() {

   $db = JFactory::getDBO();
   $this->presscontent = $db->setQuery("bla...");
}

for sure we would have to modify the interceptor method, too.

In this case the com_content-component would recieve a content_item,
with all that nice stuff like, checkin,checkout,publish, [...],
and extended informations.

The next thing is to realize that, the current architecture of the
com_content component, did not implement any plugin-Event for content
filtering, thats a issue i had to solve too. So in this case it is a
bit tricky, because there is no way until now to recieve the
resultArray of the com_content models, there is only a way to get
the single row, as far as i know.

Why?
Imagine, you have a multilanguage site. But the articles, published
in English would not be published in German or vice versa. So there
must be a kind of filter instance. the frist possiblity is to modify
the query, com_content fires (that would be a stupid thing), the
second is to modify the database class (second stupid thing).
So it would be nice to have a filter Event, where the whole result is
passed.

In that case third-party developers would be able to implement, there
on lists and logics in it. p.e.

Code: Select all

[...]
function onMyWholeResultArray(&$array,$something_useful) {
   $array = MyDecoratorFactory::getDecoratorList(&$array);
}
[...]

The List-Class could implement interfaces like ArrayAccess & Iterator.
Than you let the List-Decide to return a value or not. That is very
cool, because you never had to modify foreach or while or for statements.
p.e.

Code: Select all

[...]
   foreach($decoratorList as $key=>$value) {
      //do some tricky stuff...we donot know
   }
   
   -> decorator list
      public function __construct($list) {
         $myarray = array();
         foreach($list as $key => &$value) {
            if (method_exists($value,"isValid")) { //is this a content item?
               if (($value->isValid())) {
                  $myarray[$key]= $value;
               }
            }
            else
            {
                $myarray[$key] = $value;
            }
         }
         $list = $myarray;
         $this->list = $list;
         $this->arraykeys = array_keys($list);
   }
[...]

so the specific decorator could descide, if it would be displayed in a blog-listing or not.

Code: Select all

[...]

   function isValid() {
      if ($this->extracontent->englishOnly) {
         return false; // so there is no way to display it, in a german site
      }
   }

[...]

Because, in my current project, we use a modified joomfish on a joomla1.5 as a own database class
i did the modification there, because i don't want to touch the code of the com_content models,
but i think that this second improvement, would give us all more possibilities.

I've worked a long time with the eclipse RCP-Framework and there were extensionpoints defined,
in a extra xml file to that component. A quite nice thing. In fact the philosophy of the
Eclipse Project and its plugin-strategy is:

that everything is a plugin.


I also thought about PHP AOP to let an Aspect-Weaver do the job, so
the code of com_content, is updateable, but in runtime would be intercepted
by an defined Aspect.

ok what do you think?
how would you do this?
is there an issue i didn't thought of?
perhaps you got a better way?

i would love it, if you would let me know your thoughts about it.

greets mario
*joomla is so cool*

Hi Mario,

Interesting write-up. I just read it twice, still trying to figure out what exactly you are trying to do. So far I understand you are trying to extend com_content and you don't want to hack any of it's code. You are thinking about using a decorator pattern or even moving to espect oriented programming which I find a very interesting approach. I had never heard before about PHP AOP, I will need to do some studying on that one before I can give you feedback on how it could be used. Never the less, interesting.

Maybe you could start by giving me a better idea of what your actual goals are ? What kind of specific features are you trying to develop ?

Cheers,

Johan

Ok, sorry i was drifting away a bit. The Feature is a whole bunch of specialized contents.
And i only want to layout some new view-templates for them and use all the features of
com_content, too. So the bunch of contents (-types) are:

• 1. Events
• 2. Expositions
• 3. Statistics
• 4. Graphics
• 5. Press Releases
• 6. Generic News
• 7. PDF Archive

The approach of this specialized contents is, that it is only content,
no need for some specialized handling. But their alltogether should:

• 1. organized in categories/sections
• 2. published through the Publisher
• 3. handle checkin/checkout
• 4. and so on.

Their also have in common, that all of them have
titles, texts, publishing dates and all the other
jos_content stuff.

p.e.
Press Releases are also jos_content but
would be extendes by jos_content_pressreleases,
that brings some extra fields like

• location
• URL Link for further informations
• Download Link for some extra information
• ImageURL for an Image
• ImagePosition for the view template, say where the image has to appear
• [...] and some more

And everything has to be multilingual.

I thought, that i could do me a favour and
keep it very in touch with the joomla approach to
organise contents, because all of them are
still simple contents with some extra info.

So all i have to do is, to let the model
load me that extra info.

Thats why i want to use Decorator/Facade.
I would love to have a com_content Interface class
i could implement, but not i now i guess.

hope that give you a short overview.

website i wanna joomalize: http://www.bdli.de

cheers
mario

did you notice, my question about
a contentfilter plugin event (p.e. onContentsLoaded)

ok, very short

!SHORT!
Joomla! is a content managment system. thats clear for all,
but what is content? thats not clear i guess.

content is everything.

in my case content is an event, a document, a press release,
yeah for sure perhaps a user could be a content too.

so if everything is a content. we are able to implement
workflow items etc. at a central point.

there only have to be a kind of Joomla Pattern to implement
its additional informationen and all its formulars, datastructure, workflows comes with it.

... just an addition to my previous posts....

I'm just doing the same as Boojam.

My aproach is: (not the best one, I know).

- For the extra fields, I add/remove those fields on the install/unistall procedure to the jos_content DB table.
- Model:
  + I extend ContentModelArticle to add any extra methods that I find useful in the views.
  + I extend JTableContent and I add the extra fields as class variables, so I ensure the store method updates the jos_content with my extra fields:
- I use a custom controller to manage my logic. This controller is defined to manage basically the edit and save operations.
  + Edit: prepare the custom view for edit/new content.
  + Save: A BAD IDEA - a modified version of the save operation for com_content modified to use the custom JTable instead of JTableContent to save changes to the extra fields. Also the save logic can be modified here.
- Views:
  + New/Edit: I use a custom view, copied and modified from the com_content article view. This view is modified to use the custom Model and the form layout is modified to show the extra fields.
  + View: I use the standard com_content view, but I show the extra fields modifying the default layout in the template.

Not clean, not elegant...  but it's my best attemp.

Hi Superjose,

i guess it is not really the same thing, because
on my site i got two tables to work with:

jos_content (clean, not modified)
jos_content_pressreleases (new)

and i mapp them together, look at this:

Code: Select all

-- phpMyAdmin SQL Dump
-- version 2.6.2-pl1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Erstellungszeit: 26. März 2007 um 20:55
-- Server Version: 4.0.18
-- PHP-Version: 5.1.1
--
-- Datenbank: `bdli_rcclab_de`
--

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

--
-- Tabellenstruktur für Tabelle `jos_content`
--

CREATE TABLE `jos_content` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `title` text NOT NULL,
  `title_alias` text NOT NULL,
  `introtext` mediumtext NOT NULL,
  `fulltext` mediumtext NOT NULL,
  `state` tinyint(3) NOT NULL default '0',
  `sectionid` int(11) unsigned NOT NULL default '0',
  `mask` int(11) unsigned NOT NULL default '0',
  `catid` int(11) unsigned NOT NULL default '0',
  `created` datetime NOT NULL default '0000-00-00 00:00:00',
  `created_by` int(11) unsigned NOT NULL default '0',
  `created_by_alias` text NOT NULL,
  `modified` datetime NOT NULL default '0000-00-00 00:00:00',
  `modified_by` int(11) unsigned NOT NULL default '0',
  `checked_out` int(11) unsigned NOT NULL default '0',
  `checked_out_time` datetime NOT NULL default '0000-00-00 00:00:00',
  `publish_up` datetime NOT NULL default '0000-00-00 00:00:00',
  `publish_down` datetime NOT NULL default '0000-00-00 00:00:00',
  `images` text NOT NULL,
  `urls` text NOT NULL,
  `attribs` text NOT NULL,
  `version` int(11) unsigned NOT NULL default '1',
  `parentid` int(11) unsigned NOT NULL default '0',
  `ordering` int(11) NOT NULL default '0',
  `metakey` text NOT NULL,
  `metadesc` text NOT NULL,
  `access` int(11) unsigned NOT NULL default '0',
  `hits` int(11) unsigned NOT NULL default '0',
  `metadata` text NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `idx_section` (`sectionid`),
  KEY `idx_access` (`access`),
  KEY `idx_checkout` (`checked_out`),
  KEY `idx_state` (`state`),
  KEY `idx_catid` (`catid`),
  KEY `idx_mask` (`mask`)
) TYPE=MyISAM AUTO_INCREMENT=506 ;

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

--
-- Tabellenstruktur für Tabelle `jos_content_press`
--

CREATE TABLE `jos_content_press` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `contentID` int(10) unsigned NOT NULL default '0',
  `location` varchar(255) default NULL,
  `image` varchar(255) default NULL,
  `fileattachment` varchar(255) default NULL,
  `linkurl` varchar(255) default NULL,
  `linktitle` varchar(255) default NULL,
  `image_adjustment` varchar(255) default NULL,
  `language` int(10) unsigned default NULL,
  `write_protect` int(10) unsigned default NULL,
  `top_announcement` int(10) unsigned default NULL,
  `workflow_action` int(10) unsigned default NULL,
  `workflow_state` int(10) unsigned default NULL,
  `content_date` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`id`)
) TYPE=MyISAM AUTO_INCREMENT=148 ;

what i do is to load it on an system event onContentPrepare
and put a decorator, better a decorator-method-proxy-delegator-composite ;-)

so load, save,view is handled by the joomla classes.

no extends, only losely compositions at this point,
that is a different design aspect, it keeps the flexibility of the code,
without having monolit structures.

I just want to update my site, by overwriting the core-files.

what do you think?

i hope in future, there will be more event
we can listen to, than onPrepareContent,
or something like that.

i wish every critical code point, should have
such a nice "extensionpoint". i like the plugin architecture very much.
i love it. how we can get more, of them?

greetz mario


       

You are right Boojam.

In my first attemp to build the component for Joomla 1.5 based on content, I thought that implement the extra content funcionality as a content plugin was the better choice.

After that, I found it difficult and without any previous example I decided not to take risks on the project...and choose the easy way... 

WOW!  That was quite a read. 

From an outside perspective, it seems that you are going to end up doing WAY more work implementing decarators and filters and all of those plugin handlers to do everything you need to do than if you were to just write a component from scratch.  So, I guess the question is, why not write a special content component from scratch (obviously, you can copy from com_content)?  With Joomla! 1.5, you are not stuck with com_content.  You don't even have to use it at all if you don't want to.  You could sit down and build com_specialcontent to achieve all the things you want to do and then use that to access all of your content.  Joomla! design philosophy says that components are black boxes, they are not designed to be that extensible, that is why there probably isn't a content filter event... when you get into something like that you are altering/adjusting the logic of a component and if you are doing that, it is probably just easier to write your own component.  Just something to think about I guess.  If I were in your shoes, I would definitely write a component from scratch to handle a job like this.

Hi RobS,

yes you're right. writing my own component would be easier.
I just took this way, because i had to implement 15 of those
special contents. And everyone of them should have the
standard features of com_content.

i just was tooo lazy to write it on my own ;-)
so i got all the functionality, params, lists, views...backend and frontend
for my special content without writing extra code...

now i am finished and it works fine, really fine...
i was wondering myself about the power this little decorator-plugin
stuff has.

but for sure, components are blockboxes. so i duplicate the com_content, now
doing some lifts and call it special content. after that
i would post here the code to download, then you can look
at this ;-)

greetz mario

I'm also working around the same problematic...and Boojam's approach seems interesting.
I agree with the "specialized contents" or "how to extend com_content with aditional data either logics?" problem. Even for a little project  you should have to create one component for each "specialized contents" and 90% of code is a rewrite or hacking of com_content (very risky when there is security update or change).

Alex

>> I'm not  a great community participants  and I'm a little ashamed for that but I'd like congratulate the Core Team Members for their great work on the 1.5.

Boojam wrote:
content is everything.

in my case content is an event, a document, a press release,
yeah for sure perhaps a user could be a content too.

I agree with you, Boojam! In my case "article comments" are themselves articles of a special kind. I'm writing comments plugin/component for Joomla 1.5 and with every iteration of development it seems more and more natural to store comments in the same table as articles, but differentiate (filter) them from other articles using special Section.
Articles table already has "parentid" column, so in a case of comments I don't need any additional data table.

And of cause, Sections and Categories should be special kinds of Content (i.e. of Articles): see, how much duplicate code have views of Articles, Sections and Categories... 

Ideas are coming along, and I'm dreaming about new "TypeOfContent" field (attribute of the Article), each "Type" associated with special "content component" - just like in file system different applications are used to view files, that have different extentions...

My 2c worth ...

It would be useful to have the ability to define 'content dimensions' which are separate from com_content and it's datastore. For instance, one of our projects has articles that can 'apply'/fit into
- one or more divisions of the company (say finance, sales and presales but not consulting)
- one or more target groups for the site (say enterprise customers and partners but not new customers).

Since an article is in exactly one category, using sec/cats for such an architecture is not working.

If the content admin showed a separate pane listing the existing dimensions, and com_content (or some com_contentplus) accepted parameters to select based on such dimensions, life would be so much fun. A menu item for content would also list the known dimensions and allow you to specify selections, or even rules (such as department IN ('sales', 'presales') ...

I haven't found any decent way that would avoid hacking the com_content aka. adding my own version of it. The 'mixin' concept is attractive, but probably hinges on serious framework support ... I do like the event idea though : in another project, we use a simple model class which load a table row, but an onAfterLoad event handler is able to pick up additional attributes and join them in the data array before anyone gets their hands on it.

If you are able to create content-with-attributes and provide an API to select conten ... man oh man, how many component developers would jump on this ! Product listings, restaurant reviews, house descriptions, ... everything becomes content in reality.

Perhaps the key to this is refactoring content to be a special case of the kind of supercontent described above. Com_content would become a generic handler to create a model (single object or selection) and apply a view to it. Actually, when I looked at the 1.5 com_content compared to 1.0, which I was considering to hack, it seemed much less of an chore.

Would anyone be interested in driving specs for a contentplus component, which would have to be backward compatible with com_content ?

Joomla 2 was at some point going to be rewritten as a node based system (NBS), don't know what will happen now after the framework refactoring..
I'm expecting some news after the currently ongoing Googleplex summit and hoping for updates on roadmpa and future plans..