> datasource for the gateway and a Message model (or, some other M based
> stuff).
Possibly, I have sometimes wondered why the EmailComponent was a
component and not something else. Any time you have a feature that
does not render to the browser you end up in a bit of a design
dilemma. I took the hint from Email and stuck my stuff into a
component even though I "economized" on the design (no capturing any
MMS View or anything like that)
> anyway, controller actions are supposed to be under_scored and that's
> the 'fix' for your auth woes imo (or simply if (!empty($this->params
> ['requested'])) { $this->Auth->allow('*'); }
The thing was that this is what did not work after I updated. Allowing
would not work when the action was requested even though I allowed
everything. That is why I renamed the actions... which I should have
done from the start.
> I have a similar problem at the back of my mind, which I planned to
> solve by using a plugin component as the plugin entry point/interface,
> and therefore you'd just (either dynamically or otherwise) include the
> plugin's component in your controller to make use of it.
> It'd be neat to hear a little more about your current core
> architecture, since I have the need to do something (probably)
> similar.
Without being too lengthy (another day maybe).
The core does authentication, user management, global settings and
configurations.
The core holds models for the above things and also "common"
functionality like sms, mms messages, search-filters, phone-number log
and similar "often used" model stuff.
The core keeps all plugins in a Model that is HABTM to the User model
so that apart from normal "permission levels" each plugin can be made
available to a user (or not). Also each plugin can be set as
"installed" or not since not all out clients should have all plugins
but pulling the same source to each vhost simplifies updates a lot
(and I can "install" a new feature for a client in a second).
Every plugin can, for example, save their own smses in the core model.
I use a field called "belongsTo" in a few of these models so that it
is possible to list only items belonging to that plugin. The
Newsletters plugin would have a model setup like NewsletterMessage-
>hasOne->Sms and hasMany->NewsletterRecipients->belongsTo-
>Phonenumber and so on. (belongsTo is used because any number of
models can be linked to the same number and should globally respect if
that number is blocked for example)
When a message arrives to the Gateway it gets parsed and stored. The
appropriate plugin is notified and given the id of the new message and
can react to it as is sees fit. The same goes for cron tasks which
notifies each plugin to "update" (= do whatever it needs to do on a
regular basis). Since the plugin decides what to do I feel more
comfortable using the "controller level" than keeping such decision
making in a model.
I did start out doing these things in models but often found tasks and
situations that asked for or "required" components , rendering, or
other non-model stuff. Each plugin would require a Pluginname model
who's purpose would solely be to decide which other Model(s) to wake
up. I might try it again but it is not at the top of my (long) todo
list. :)
What aspects of the core architecture were you interested in? Feel
free to ask for more if you are interested. Id be happy to answer and
detail any part of it you find interesting.
/Martin
On Mar 27, 11:56 am, AD7six <andydawso...@gmail.com> wrote:
> On Mar 26, 3:41 pm, Martin Westin <martin.westin...@gmail.com> wrote:
>
> > Yes I use it a lot... only for a limited purpose but throughout the
> > application.
>
> > I actually have two reasons for using it :)
>
> > Reason 1: Yoy are close. Not email but similar componets none the
> > less. I have my two components for sending mobile messages (sms and
> > mms). The application does in some plugins scheduled newsletters. It
> > can also be messages send by some system event (recieving a message
> > for example can send an automatic reply)
>
> Sounds like you've got a component where you should probably have a
> datasource for the gateway and a Message model (or, some other M based
> stuff).
>
> I have an email model (which internally - either sets up a controller
> and the email component and renders the view to get the content, or
> calls requestAction with appropriate params), and payment model (same,
> for the HTTPSocket content) for the same sort of reasoning.
>
> > Reason 2: plugins. Everything in my app is plugins except a core doing
> > common stuff. I use the PluginnameController in each to handle system
> > integration. I could have chosen to load up a Pluginname model instead
> > but since I very often need to be at the controller level (because of
> > reason 1) there was little point.
>
> I have a similar problem at the back of my mind, which I planned to
> solve by using a plugin component as the plugin entry point/interface,
> and therefore you'd just (either dynamically or otherwise) include the
> plugin's component in your controller to make use of it.
>
> > I don't use plugins at all as "standalone mini applications unrelated
> > to the rest of the application"
> > I use them much like normal desktop applications do. The core is
> > independent of the plugins but each plugin relies heavily on the core
> > for a lot of things.
>
> It'd be neat to hear a little more about your current core
> architecture, since I have the need to do something (probably)
> similar.
>
>
>
> > I would love to figure out some other good way to deal with plugin-
> > interaction... so far requestAction is it.
>
> anyway, controller actions are supposed to be under_scored and that's
> the 'fix' for your auth woes imo (or simply if (!empty($this->params
> ['requested'])) { $this->Auth->allow('*'); }
>
> AD
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment