<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 13.04.2011 um 21:27 schrieb Camillo Bruni:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Indeed this is what I had more or less in mind. Though my application won't require login hence the first three steps won't be required.<div><br></div><div>But the problem for me right now is how to specify the mapping of the url to a component with a specific state. I think REST provides nice solution by specifying the mappings non-centralized using pragmas. For instance in Django (my only field of knowledge so far ;)) you define a urls dictionary which basically consists of associations of regular expressions and methods.</div><div><br></div><div>The problem right now is that REST does not nicely interact with component rendering, though I guess that can be fixed with some helper methods which do the proper setup. However I think it would be nice to somehow able to define the mapping in a tree and not just a flat top-level thing.</div><div><br></div><div>So for instance in the following (non-origin related) example,</div><div><br></div><div>/country/Switzerland/city/Biel</div><div>/country/Switzerland/languageRegion/Romandie<br><div><br></div><div>, there would be a Country component which then decides upon the left-over url piece to either render a city subcomponent or a region subcomponent. (Though one might argue that there is an n to one mapping of cities onto languageRegions, this is not necessarily the case in Switzerland). Hence in this case it would be really cool to let the country component decide on which subcomponent to render, using the same pragma-based approach.</div><div><br></div><div>I am just interested in a particular solution solving my case ;) => a more generic dispatcher which calls some functions based on the incoming url/request.</div><div><br></div><div>IMO this is something Seaside really lacks of. Though it is unbeaten in quickly writing a form-based application, you start to struggle to cleanly design an application with restful URLs. (Which IMO is a basic feature).</div><div><br></div></div></div></blockquote>I think you just discovered a gap. Seaside provides the component classes to build your own components. But it doesn't help you in how to arrange those components into an application. Well, a component can have children. So a normal situation might be that the structure is internal to the components. If you like to manage or discover a certain component it would mean the components expose the structure there in. </div><div>A few years ago I did something I called WebComponentTree. It can be considered as web app configuration class. In this class components were arranged in a tree and every node defined the way the children are arranged and had a label/id. This way I could map a path to a component. In initialRequest: you just need to traverse the tree to find the corresponding node. If found the node can display itself taken the configuration. The same internal navigation was done using Announcements. I just used an announcement (service request) and the component at any path reacted (service offer) So you need something that deals with the application structure. I'm not confident this is easy to achieve in a generic way.</div><div>If I do stuff for which I need proper URL handling I use pier as the web application base. Pier might be a bit too complex. But then it is a construction kit for site structure, gives you some templating mechanism and adds security on top. All of these makes my life easier if they are just there.</div><div><br></div><div>Norbert</div><div><br></div><div><br></div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 2011-04-13, at 20:49, Sebastian Sastre wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>as reference, for <a href="http://airflowing.com/">airlfowing</a> we are: </div><div><br></div><div>1. creating a normal session </div><div>2. remembering the #initialRequest: </div><div>3. presenting the login in (but only if the visit doesn't have a valid login cookie)</div><div>4. if logins ok, the service creates the main component and receives (a clone of) the initial request</div><div>5. it gets parsed and delegated until it reaches the component with relevant responsibility (if not degrades gracefully). Hint: the subcomponets are created lazily.</div><div><br></div><div>Nothing fancy, no sophistication nor generic solution but it gets the thing done intuitively, without complications and clean code</div><div><br></div><div><a href="http://twitter.com/sebastianconcpt">sebastian</a></div><div><br></div><div>o/</div><div><br></div><div><br></div><div><br></div><div><div>On Apr 13, 2011, at 12:38 PM, Camillo Bruni wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>I am onto building test website in seaside which should have nice urls. I stumbled upon the Seaside-REST package, which seems like a nice solution to map the urls onto state and components.<br><br>However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method.<br><br>This is how I imagine it should work: <br>request -> stateful request handler -> choose component and initialize state -> render component<br><br>What is the proper way to do this?<br><br>Thanks,<br>Camillo_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br></div></blockquote></div><br></div>_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br></blockquote></div><br></div></div></div>_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br></blockquote></div><br></body></html>