http://www.assembla.com/wiki/show/dKAZuYVVSr3lc5abIlDkbG
On Sun, Oct 30, 2011 at 12:35 PM, hammett <[email protected]> wrote: > I've looked it up unsuccessfully. Link? > > On Sun, Oct 30, 2011 at 5:30 AM, Sebastien Lambla <[email protected]> > wrote: > > You may want to have a look at snooze, they experimented with those kind > of ideas 3 or 4 years ago > > ________________________________________ > > From: [email protected] [ > [email protected]] on behalf of hammett [ > [email protected]] > > Sent: 30 October 2011 01:24 > > To: [email protected] > > Subject: Re: Disruptive design needed for next gen of web frameworks (?) > > > > many aspects play into this picture. you mentioned two of them (OOP > > and storage). But there's also DDD (Account may be the aggregate root, > > so there's no way to access entities bypassing the account), > > authorization (user x cannot load this account or view this > > subscriber).. > > > > That's why I believe these aspects should be modeled and visible in a > > hierarchy, instead of route configurations. I'm just very unclear on > > how to actually do it :-) > > > > > > > > > > On Sat, Oct 29, 2011 at 5:49 PM, Rafael Teixeira <[email protected]> > wrote: > >> I can only think of this kind of composite route occurring when we model > >> data in a NoSQL fashion where not every piece of data is guaranteed to > have > >> an unique (primary key). > >> If you guarantee unique keys for each object in the model, we just use > pure > >> REST for navigation and thus get back to 'flatter' routes: > >> /Lines/123123189 is line 425-555-1010 of subscriber 1 of account 1002 > >> Even on a NoSQL scenario we can imagine that the lines controller can't > >> truly work on second-level nested data of a document, so it would be > >> possible to just map a route with a composite key > >> /Lines/1002/1/425-555-1010 > >> The problem which is also a problem on object-modeling x > document-modeling > >> is really if you have multiple navigations, relations on SQL, to arrive > at > >> the "Line" data... > >> Not sure I helped to think into the proposed question, but I think we > should > >> consider if RESTfulness is a driver and also SQL/NOSQL optimization, as > >> those may drive away from the nested routes scenario. > >> Just my fried brain cells speaking, > >> Fun, > >> Rafael "Monoman" Teixeira > >> --------------------------------------- > >> "The most exciting phrase to hear in science, the one that heralds new > >> discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" > >> Isaac Asimov > >> US science fiction novelist & scholar (1920 - 1992) > >> > >> > >> On Sat, Oct 29, 2011 at 10:05 PM, hammett <[email protected]> wrote: > >>> > >>> I'm starting to think that this flat representation of resources in > >>> the rails-style breed of MVC frameworks is quite deficient for today's > >>> requirements of apps. A domain is hardly flat, and the deeper you get > >>> the more context you need > >>> > >>> For example > >>> > >>> /Account/1002/Subscribers/1/Lines/425-555-1010/ > >>> > >>> With today's framework's you'll end up activating the Lines > >>> controller, passing an id. What Account/Subscribers and their ids? One > >>> trick is to pre-load those by using hierarchical routes. MR3 routing > >>> supports this. The issue I have is that this is too decoupled from the > >>> controllers (they continue to be flat) > >>> > >>> Using Routing > >>> > >>> For("/Account/:id").Config(c => { > >>> c.For("/Subscribers/:id").Config( c2 => { > >>> c2.For("/Lines/:id") ... > >>> }); > >>> }); > >>> > >>> We could potentially pre-load each account, subscriber and pass it > >>> along to the LinesController, but I'm not convinced this is a good > >>> design. > >>> > >>> Thoughts? > >>> > >>> > >>> -- > >>> Cheers, > >>> hammett > >>> http://hammett.castleproject.org/ > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Castle Project Development List" 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/castle-project-devel?hl=en. > >>> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Castle Project Development List" 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/castle-project-devel?hl=en. > >> > > > > > > > > -- > > Cheers, > > hammett > > http://hammett.castleproject.org/ > > > > -- > > You received this message because you are subscribed to the Google > Groups "Castle Project Development List" 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/castle-project-devel?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Castle Project Development List" 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/castle-project-devel?hl=en. > > > > > > > > -- > Cheers, > hammett > http://hammett.castleproject.org/ > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" 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/castle-project-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
