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 <[email protected]> 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 <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
