Re: Plugin architecture and plugin limitations

[Grzegorz Pawlik]

It's an idea that just came up. Probably You could set up some kind of
PluginHandler, which will handle the plugins instalation process
(which i describe below) and plugin interacting.

Each plugin knows where it need to inject himself into (I'll just call
it widgets for now). IE:
- extend Dog with hasOne Kennel
- add div to dog/edit with select tag that will allow to choose kennel
for the dog
I'll just stop here to keep it simple.

So Installing KennelPlugin would mean that You need to save this
widgets information into database.

Now in Dog model contstructor You could ask PluginHandler if You have
any relations to bind (You can bind Models on the fly in Cake),
PluginHandler will answer
You need to bind Kennel model with as hasOne relation

In dog/edit view, You ask PluginHandler if there's any widget that You
need to show? PluginHandler will answer, that You need to call (by
requestAction I suppose) a kennels/show_select_tag in Kennel plugin
(so it would be like echo $this-requestAction('kennel/kennels/
show_select_tags'). Probably You should force the convention that all
plugin actions have model:ModelName parameter passed (model:Dog in our
example) so the plugin could act differently when called by Dog model,
and KennelShop model wich have HABTM Kennel(s).

So in our example in kennel/kennels/show_select_tags view You would
generate sth like
$form-select('Dog.kennel_id', $kennelsList) when called by Dog
and
$form-select('Kennel.Kennel', $kennelsList, array('multiple' =
true)) when caleld by KennelShop

Ok. I'll stop here. I'm aware of that there's lots of stuff to think
of (ie. how to handle some more complex activities than adding field
to form and just save $this-data like file uploading and stuff). But
it's just a glimpse of an idea. What do You think of that?


On Apr 17, 7:38 am, John Andersen j.andersen...@gmail.com wrote:
 Thanks Jaime,

 As I understand it:
 1) The user interface (UI) is completely managed in the browser
 environment.
 2) The business logic (BL) is managed in a CakePHP application in the
 server environment.
 3) The storage logic is managed partly by the CakePHP application and
 a database engine (MySQL).
 4) Communication between UI and BL is messages with data only.

 The primary issue as I see it:
 1) Is the communication (messages) definitions independent of both UI
 and BL?

 If this is not the case, then yes, it will be very difficult to add
 new functionality without having to rewire other parts.

 Possible solution idea (configurable message based framework):
 1) UI: sends only informative messages (I have done this message) with
 data.
 2) BL: processes informative messages in one controller only, using
 request action to inform other controllers.
 3) BL: uses a configurable message handling, so that new message
 handling can be added when new functionality is implemented.

 Example (simple):
 Use case:
 The UI implements the presentation of a photo album with 10 thumbnails
 shown per page.
 The user can open the photo album, turn the pages and choose a
 thumbnail to see the full photo.

 Work flow:
 1) User opens the photo album.
 1.1) UI sends the message open photo album.
 1.2) BL looks up the configuration for open photo album
 1.2.1) BL invokes request action to PhotoAlbumController for action
 Open.
 1.2.1.1) PhotoAlbumController processes the action and returns the
 photoalbum data.
 1.2.2) BL prepares new message photo album opened with the returned
 photoalbum data.
 1.3) BL delivers the message photo album opened with the data.
 1.4) UI presents the data in the photo album opened message.

 2) User chooses a thumbnail.
 2.1) UI sends the message photo thumbnail chosen.
 2.2) BL looks up the configuration for photo thumbnail chosen.
 2.2.1) BL invokes request action to PhotoController for action Show.
 2.2.1.1) PhotoController processes the action and returns the photo
 data.
 2.2.2) BL prepares new message photo shown with the returned photo
 data.
 2.3) BL delivers the message photo shown with the returned photo
 data.
 2.4) UI presents the photo.

 Now comes the time that new functionality is requested, when choosing
 a photo, the photo may have a sound track associated with it, which is
 to be played when showing the photo.

 The changes are implemented as:
 2) User chooses a thumbnail.
 2.1) UI sends the message photo thumbnail chosen.
 2.2) BL looks up the configuration for photo thumbnail chosen.
 2.2.1) BL invokes request action to PhotoController for action Show.
 2.2.1.1) PhotoController processes the action and returns the photo
 data.
 2.2.2) BL prepares new message photo shown with the returned photo
 data.
 2.2.3) BL invokes request action to SoundController for action
 PhotoSound.
 2.2.3.1) SoundController processes the action and returns the sound
 data.
 2.2.4) BL prepares new message sound playing with the returned sound
 data.
 2.3) BL delivers the messages photo shown and sound playing with
 the returned data.
 2.4) UI presents the photo 

Re: Plugin architecture and plugin limitations

[Richard]

Hi all,

How this would apply with the CakePHP framework I'm unsure, but I use
interfaces extensively in modular platforms when defining classes. I've
used CakePHP mainly as a presentation control layer, with the external work
occuring in libraries. My CakePHP plugins provide an integration layer to
software developed in PHP, which does use interfaces. This is for data
processing, rather than extracting data for presentation, but that's the
domain of the software being worked with at the moment.

I've thought over ways to bring this approach to CakePHP and the plugin
structure, and have experimented with this approach. Some routes simply
resulted in bloat (interfaces to generate dynamic javascript was one genious
piece of bloatware) Another thing that I found though, doing dependency
matching in plugins was a complete nightmare, and it was simpler and less
prone to error to to state in documentation This plugin requires X plugin,
than create some code-driven platform to handle it. It could be that the
dependency checking was over complicated in it's implementation.

A CMS I've developed with CakePHP didn't use Plugins directly, but had a
view was overridden to allow plugins intercept the generated output. It was
a bit more involved than I'm detailing here, and wasn't the cleanest
approach, but it might be a step in a direction worth investigating more.

class PluginView extends View {
...
function beforeRender() {
   foreach ($this-observed as $observed) {
$observed-parse($this-__buffer, $this);
   }
}
}

Hope this has been help, even if it rules out bad ideas :)

Richard

On Fri, Apr 17, 2009 at 9:42 AM, Grzegorz Pawlik
grzegorzpaw...@gmail.comwrote:


 It's an idea that just came up. Probably You could set up some kind of
 PluginHandler, which will handle the plugins instalation process
 (which i describe below) and plugin interacting.

 Each plugin knows where it need to inject himself into (I'll just call
 it widgets for now). IE:
 - extend Dog with hasOne Kennel
 - add div to dog/edit with select tag that will allow to choose kennel
 for the dog
 I'll just stop here to keep it simple.

 So Installing KennelPlugin would mean that You need to save this
 widgets information into database.

 Now in Dog model contstructor You could ask PluginHandler if You have
 any relations to bind (You can bind Models on the fly in Cake),
 PluginHandler will answer
 You need to bind Kennel model with as hasOne relation

 In dog/edit view, You ask PluginHandler if there's any widget that You
 need to show? PluginHandler will answer, that You need to call (by
 requestAction I suppose) a kennels/show_select_tag in Kennel plugin
 (so it would be like echo $this-requestAction('kennel/kennels/
 show_select_tags'). Probably You should force the convention that all
 plugin actions have model:ModelName parameter passed (model:Dog in our
 example) so the plugin could act differently when called by Dog model,
 and KennelShop model wich have HABTM Kennel(s).

 So in our example in kennel/kennels/show_select_tags view You would
 generate sth like
 $form-select('Dog.kennel_id', $kennelsList) when called by Dog
 and
 $form-select('Kennel.Kennel', $kennelsList, array('multiple' =
 true)) when caleld by KennelShop

 Ok. I'll stop here. I'm aware of that there's lots of stuff to think
 of (ie. how to handle some more complex activities than adding field
 to form and just save $this-data like file uploading and stuff). But
 it's just a glimpse of an idea. What do You think of that?


 On Apr 17, 7:38 am, John Andersen j.andersen...@gmail.com wrote:
  Thanks Jaime,
 
  As I understand it:
  1) The user interface (UI) is completely managed in the browser
  environment.
  2) The business logic (BL) is managed in a CakePHP application in the
  server environment.
  3) The storage logic is managed partly by the CakePHP application and
  a database engine (MySQL).
  4) Communication between UI and BL is messages with data only.
 
  The primary issue as I see it:
  1) Is the communication (messages) definitions independent of both UI
  and BL?
 
  If this is not the case, then yes, it will be very difficult to add
  new functionality without having to rewire other parts.
 
  Possible solution idea (configurable message based framework):
  1) UI: sends only informative messages (I have done this message) with
  data.
  2) BL: processes informative messages in one controller only, using
  request action to inform other controllers.
  3) BL: uses a configurable message handling, so that new message
  handling can be added when new functionality is implemented.
 
  Example (simple):
  Use case:
  The UI implements the presentation of a photo album with 10 thumbnails
  shown per page.
  The user can open the photo album, turn the pages and choose a
  thumbnail to see the full photo.
 
  Work flow:
  1) User opens the photo album.
  1.1) UI sends the message open photo album.
  1.2) BL looks up the configuration for 

Re: Plugin architecture and plugin limitations

[Jaime]

 Our lame but necessarily practical/quick solution was to give up on
 plugins. [...]

I'm afraid we will do the same. This application will have *a lot* of
Javascript which also needs to be modular and extensible. I think
there won't be any problems making pluggable components for the client
part, because of prototypal inheritance in JS.

What a pity this is not possible in PHP.

 Not exactly an answer to your question but maybe a bit of our
 experience will bring up some ideas or nourish the discussion here.

It would be great to read some more ideas here.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---

Re: Plugin architecture and plugin limitations

[John Andersen]

Sounds interesting!
Could you show some examples (code, ideas, whatever) of what you tried
to accomplish, so the CakePHP community can grow from your experience
and/or maybe provide additional information to assist in finding a
solution?
Enjoy,
   John

On Apr 16, 12:28 pm, Jaime ja...@iteisa.com wrote:
  Our lame but necessarily practical/quick solution was to give up on
  plugins. [...]

 I'm afraid we will do the same. This application will have *a lot* of
 Javascript which also needs to be modular and extensible. I think
 there won't be any problems making pluggable components for the client
 part, because of prototypal inheritance in JS.

 What a pity this is not possible in PHP.

  Not exactly an answer to your question but maybe a bit of our
  experience will bring up some ideas or nourish the discussion here.

 It would be great to read some more ideas here.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---

Re: Plugin architecture and plugin limitations

[Jaime]

 Could you show some examples (code, ideas, whatever) of what you tried
 to accomplish, so the CakePHP community can grow from your experience
 and/or maybe provide additional information to assist in finding a
 solution?

There is no single line of code, nor will be until all the application
architecture is clearly defined and probed. The goal is to build a
Rich Internet Application (RIA) as a service (SaaS) for the management
of a large travel agency. Current solutions I've seen are built on top
of desktop platforms such as Microsoft Dynamics Navision or as
standard server/client intranets.

Both approaches have limitations: desktop applications cannot be
accessed from outside the company without installing software on the
computer. Web applications can, but are less usable and have a slower
response.

I'm interested in approaching this problem from a different
perspective, trying to combine the best of the two worlds: a server/
client architecture over HTTP, but the server streaming just JSON or
XML after AJAX requests instead of rendering web (X)HTML pages.

Have a look at this: http://qwikioffice.com/desktop-demo/login.html

The UI can be built directly on the DOM of the web browser by
extensive use of Javascript. I'm planning to use the ExtJs (extjs.com)
framework on the client for that. DOM generated controls combined with
AJAX requests are far more powerful than standard HTML form widgets.

So the scenario now is a little more complex: there are two apps (one
in the server and one in the client) instead of one. And they are
binded in a data-centric fashion just by JSON data (no code nor markup
between).

On the server side I plan to use a RDBMS such as MySQL or PostgreSQL
and CakePHP. There will be no (X)HTML views except for the frontpage.
When the user triggers an action in the UI, an AJAX request is sent to
the server and attended by a controller, which will send back just a
JSON with the requested data (may be a list or a record from the DB).

The pros of this approach are obvious for the user, which would be
able to use a web application as a single-page website, with the
benefits of desktop software: good responsiveness and shortest delays
between actions.

As an example, the user can open two windows (JS modal windows) in the
same browser tab, each with different views (say the passenger list of
two different flights) at the same time for comparing, as well as to
move the windows around, resize them or edit different records at the
same time. This is not possible with the traditional intranet
approach, where requesting a view necessarily closes the previous
one.

Such an application needs to be extensible. A tiny core can be easily
built to provide a basic interface to customers, workers, targets and
flights, but a client may ask to a solution for managing terrestrial
transport (buses, drivers, stops, timetables...). Implementing this
into the core would add extra complexity and affect the stability for
sure.

This is why I'm interested and making some little research these days
about how to build a plugin architecture for a MVC application running
over PHP. AFAIK there wont be a problem in the client side, because
Javascript objects can be redeclared and extended easily, but none of
this can be done with PHP and Cake. Or at least that's what I have
came up to.

I find this is very interesting because such a plugin architecture can
be later applied to many other applications and scenarios.

Feel free to share your thoughts or experiences here in this thead.

--
jaime a t iteisa d o t com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---

Re: Plugin architecture and plugin limitations

[Jaime]

A *VERY interesting* reading on the subject:

http://blog.fedecarg.com/2008/06/28/a-modular-approach-to-web-development/

MVC is about loose-coupling, and Modular Programming takes that
concept to the extreme. A modular application can dynamically load and
unload modules at runtime, completely separate applications in their
own right, which interact with the main application and other modules
to perform some set of tasks.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---

Re: Plugin architecture and plugin limitations

[John Andersen]

Thanks Jaime,

As I understand it:
1) The user interface (UI) is completely managed in the browser
environment.
2) The business logic (BL) is managed in a CakePHP application in the
server environment.
3) The storage logic is managed partly by the CakePHP application and
a database engine (MySQL).
4) Communication between UI and BL is messages with data only.

The primary issue as I see it:
1) Is the communication (messages) definitions independent of both UI
and BL?

If this is not the case, then yes, it will be very difficult to add
new functionality without having to rewire other parts.

Possible solution idea (configurable message based framework):
1) UI: sends only informative messages (I have done this message) with
data.
2) BL: processes informative messages in one controller only, using
request action to inform other controllers.
3) BL: uses a configurable message handling, so that new message
handling can be added when new functionality is implemented.

Example (simple):
Use case:
The UI implements the presentation of a photo album with 10 thumbnails
shown per page.
The user can open the photo album, turn the pages and choose a
thumbnail to see the full photo.

Work flow:
1) User opens the photo album.
1.1) UI sends the message open photo album.
1.2) BL looks up the configuration for open photo album
1.2.1) BL invokes request action to PhotoAlbumController for action
Open.
1.2.1.1) PhotoAlbumController processes the action and returns the
photoalbum data.
1.2.2) BL prepares new message photo album opened with the returned
photoalbum data.
1.3) BL delivers the message photo album opened with the data.
1.4) UI presents the data in the photo album opened message.

2) User chooses a thumbnail.
2.1) UI sends the message photo thumbnail chosen.
2.2) BL looks up the configuration for photo thumbnail chosen.
2.2.1) BL invokes request action to PhotoController for action Show.
2.2.1.1) PhotoController processes the action and returns the photo
data.
2.2.2) BL prepares new message photo shown with the returned photo
data.
2.3) BL delivers the message photo shown with the returned photo
data.
2.4) UI presents the photo.

Now comes the time that new functionality is requested, when choosing
a photo, the photo may have a sound track associated with it, which is
to be played when showing the photo.

The changes are implemented as:
2) User chooses a thumbnail.
2.1) UI sends the message photo thumbnail chosen.
2.2) BL looks up the configuration for photo thumbnail chosen.
2.2.1) BL invokes request action to PhotoController for action Show.
2.2.1.1) PhotoController processes the action and returns the photo
data.
2.2.2) BL prepares new message photo shown with the returned photo
data.
2.2.3) BL invokes request action to SoundController for action
PhotoSound.
2.2.3.1) SoundController processes the action and returns the sound
data.
2.2.4) BL prepares new message sound playing with the returned sound
data.
2.3) BL delivers the messages photo shown and sound playing with
the returned data.
2.4) UI presents the photo and plays the sound.

Conclusion:
The important part of the above, is that the UI and the BL are
independent of each other. This is done by having messages that are
independent of both UI and BL, but the messages can be understood by
both!

Well, not easy only using text to present a message based solution :)

Hope this helps you on the way,
   John


On Apr 16, 9:09 pm, Jaime ja...@iteisa.com wrote:
 A *VERY interesting* reading on the subject:

 http://blog.fedecarg.com/2008/06/28/a-modular-approach-to-web-develop...

 MVC is about loose-coupling, and Modular Programming takes that
 concept to the extreme. A modular application can dynamically load and
 unload modules at runtime, completely separate applications in their
 own right, which interact with the main application and other modules
 to perform some set of tasks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---

Plugin architecture and plugin limitations

[Jaime]

Hi all,

Consider a big Cake application which could be divided into a small
core and many plugins providing extended funcionality. Pretty much as
Wordpress is built: tiny, efficent core, and pluggable extensions
connected by hooks. The same applies to MediaWiki, to cite just
another wide known example.

I'm getting trouble in figuring out how to accomplish this plugin
architecture using our favourite framework. Cake plugins are a cool
way to pack and reuse functionality, but they are not designed to
provide full extensibility with clean interfaces. These are the
limitations I find:

1.- A plugin cannot extend a model defined in the core. It would be
great to have, say, a Dog belongsTo Person relationship defined in
the Model and letting the Dogstar plugin to add a new Video Model
and a Dog hasMany Video relation to the Dog Model. So the results of
Dog-find('all') would vary depending on whether the plugin is
installed or not.

2.- A plugin may extend a Controller too, like for adding a bark()
action to the DogsController. New controllers can be defined in a Cake
plugin, of course, but I haven't found a clean way to extend a
Controller which has already been defined in the core.

3.- Plugins may also alter the views, as it can happen with Wordpress
or MediaWiki plugins, for example. If the Dogstar plugin is
installed, a new div/ element with Videos would be added to every
page, for example.

4.- A plugin may come with a SQL file which would add some new tables
or new columns to existing tables in the application SQL schema.

So those are my thoughts and the limitations I've found while trying
to think about an extensible, modular application with could be
extended by plugins with clean interfaces.

I think this is an interesting topic, as the benefits of such a
powerful plugin architecture go without saying: a small core is easier
to maintain, and packing features in plugins reduce testing costs, for
example.

I'm sure many of you have more experience than me in this area. I'd
like to discuss this approach with you: how would you implement a
plugin system like the one described on a MVC framework?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---

Re: Plugin architecture and plugin limitations

[unimatrixZxero]

Out of lack of time and some frustration I've come to the same stall.
We had a similar situation to yours about three weeks back. We fiddled
a lot and tried to work around the limitations given by Cake and PHP.
I say and PHP because classes are inherently closed in PHP vs. Ruby
where a plugin can re-open classes and add (to use your example) a bark
() method/action to the DogsController.

Our lame but necessarily practical/quick solution was to give up on
plugins. For everything that really has to hook into the core; seeing
our system will stay in-house and new modules/plugins are mostly one
off edge cases for customer requests we'll just take our core system
and add to it.

Not exactly an answer to your question but maybe a bit of our
experience will bring up some ideas or nourish the discussion here.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to 
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---