Thanks Kelly! On Sun, Oct 30, 2011 at 12:38 PM, Kelly Leahy <[email protected]> wrote: > 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. >
-- 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.
