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.com>wrote:
>
> 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 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
-~----------~----~----~----~------~----~------~--~---
