Yehuda,
Sorry about the last email I sent it without meaning to.
This is very interesting!
MVC reminds me of Objects. An object has a view (its interface), it
has a controller (its code), and it has a model (the instance
variables, and code to deal with the instance variables).
Now, an App has two MVC's: the ENTIRE App has its own interface (API/
UI), has its own controller (the full body of code of the app, with
the computers that process the code), and its own model (the business-
rules objects or resources).
Then there's the actual insides of the app, which has its views (the
code that builds the API/UI), its controllers (the controller-level
code) and its own model (all the storage-based objects).
What is interesting to me, is that the way the app handles the
resources, because all of the way the app handles its resources are
actually another meta-layer on TOP of the "ENTIRE APP" (business
application) layer... validation is really a level of concern that is
at the business-rules level, driven from above that, yet it gets stuck
into the insides of the app's model layer.
"A person's name should be no larger than 20 letters long" is a
business-rules decision. "A person shall have between zero and fifteen
employees" is another one, albeit more complex.
At present, we have no place to put these rules. The actual
implementation of the constraints and rules appears in the model
objects, but they're actually driven from somewhere else: I might have
another application with an identical model set, except they might
have up to 32 employees. The model should be identical, though,
surely! This brings to light interface-level validation. Surely the
interface should know of the application(business)-rules of how to
validate a password, for example, otherwise the back-end has to be
queried before validation information can be passed through.
Validating a telephone number shouldn't HAVE to be a trip back to the
server (unless giving away JS-validation-code is an issue, in which
case it CAN be a trip back to the server).
It makes little sense to me that this validation information should be
in the model, because it's really not the concern of the model. It's
the concern of the constraints and authentication of the information
(models), which is what you're calling here the resource.
So, to recap, we have two "programs", one of which is enclosed by the
other.
The business program, which may or may not actually use computers. It
is comprised of a set of business rules, a set of business methods or
practices, and also a set of business schemas. The business program
drives and encloses the computer program. We currently have very good
tools to model (and therefore describe) the computer program
components of a business program, but our ability to model businesses
presently sucks because we haven't begun to model that layer very
well. If we did, we'd end up being able to model patterns of reuse for
businesses, and this would be very exciting.
We'd end up with a program which would have self-documentation (ie all
tests and therefore requirements built into classes, not accessed
until actually required by use, but there nonetheless) with code that
could describe its use, also, not to mention a business that could
describe how it worked if need be. It would be obvious to the
programmer WHY each bit of code was exactly where it was, and if the
business rules changed, refactoring would be much simpler.
Julian.
On 15/11/2008, at 3:44 PM, Yehuda Katz wrote:
> Julian,
>
> In my opinion, part of the missing link for the fat-model, skinny-
> controller argument is that there's a missing, almost etherial
> object. It's called the "resource". In Rails and current Merb, a
> resource is just a set of router macros that are very difficult to
> extend.
>
> Some scenarios that make implicit use of this etherial object:
> * authorization: "allow only foo users access to do <some action> to
> this resource"
> * cache expiry: "when this resource changes, expire its controller"
> * URL lookup: "give me the URL for <some action> on this resource"
> * multiple models in a single form: "confirm that these associated
> objects are valid"
> * a form that's backed by a non-ORM backend: "this form should
> populate a web-service"
>
> At the moment, a lot of that is done either in the controller of
> model, but it's out of place in both. Why? Because this "resource"
> is really a composite of the current request (and its associated
> session) and the model (which may or may not be backed by an ORM).
> The solution: hydrate this object and make it usable by end-users.
> The timeline: ... ;)
>
> -- Yehuda
>
> On Fri, Nov 14, 2008 at 5:05 PM, Julian Leviston
> <[EMAIL PROTECTED]> wrote:
>
> That seems like a spastic place to put it, to me.
>
> What if you want to re-use your models at a later date? If so, you've
> got some kind of URL-bindings in them... what if the models aren't
> even being used in a merb or rails app?
>
> Way to tie the models to the app forever!
>
> This is the problem with Rails - it doesn't focus on re-use enough. If
> I remember correctly DHH even said something akin to you're better off
> rolling a fresh project each time from memory.
>
> Me? I'd prefer drop-in-reusable code.
>
> This push towards tiny controllers is a bit stupid, IMHO. The
> controllers essentially are the core glue of your app. The view layer
> is the part where the user interfaces with your app, and this (as far
> as I'm concerned) includes the URL - this is a part of the user-
> interface to your app. Thus, the router is part of the view layer.
>
> Therefore, the router should be the place to specify this. The
> documentation is a little light on, isn't it?
>
> So far as I can see, the way to do this would be a named route thusly:
>
> # in your routes file
>
> Merb::Router.prepare do
> match("/location/:id-:name").to(:controller
> => :location, :action
> => :show).name("location")
> end
>
> # usage - in view files
>
> url(:location, location, location.name)
>
> It would be nice to be able to specify methods of arguments:
>
> Merb::Router.prepare do
> match("/location/:id-#{argument_1.id.as(:id)}").to(:controller
> => :location, :action => :show).name("location")
> end
>
> but that looks really messy and convoluted. There must be a simpler
> solution: I'd wager it'd be off the beaten-track of rails-like routes.
> Surely we've outgrown them in flexibility and function. Shit, I know
> Rails has!
>
> Essentially what would we're aiming at is a good way to specify
> matching 'location/' then a named (:id) parameter that represents the
> first object's id method, then a named parameter (:name) that
> represents the first object's name method.
>
> Food for though.
>
> Julian.
>
> On 15/11/2008, at 11:33 AM, [EMAIL PROTECTED] wrote:
>
> >
> > hi,
> > how can i define the routes such that url(:location, location) would
> > generate this url "/location/3-san_diego" rather than "/location/3"
> >
> > I don't understand this help page
> > http://wiki.merbivore.com/howto/router
> >
> > In Rails, I can define the url in the model, not the routes file
> using
> > def to_param "#{id}-#{name}" end
> >
> >
> > O Nov 13, 11:40 am, "Michael Klishin" <[EMAIL PROTECTED]>
> > wrote:
> >> 2008/11/13 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> >>
> >>> Won't the router just catch urls, not define them?
> >>
> >> Router defines rules for both recognition and generation. Same
> thing
> >> in Django, Rails, Pylons and wherever else you can find the same
> >> routing table approach.
> >> --
> >> MK
> > >
>
>
>
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"merb" 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/merb?hl=en
-~----------~----~----~----~------~----~------~--~---
