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.
