Rendering Component in a WAPragmaBasedRestfulHandler
Locked
Rendering Component in a WAPragmaBasedRestfulHandler
 
|
Hi,
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. However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. This is how I imagine it should work: request -> stateful request handler -> choose component and initialize state -> render component What is the proper way to do this? Thanks, Camillo_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
Hi Camillo,
I have just published a draft of a tutorial about Seaside-Rest (in french). http://www.auverlot.fr/index.php?z=21 Hope that could help you. Best regards Olivier ;-) www.auverlot.fr Le 13 avr. 2011 à 17:38, Camillo Bruni a écrit : > Hi, > > 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. > > However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. > > This is how I imagine it should work: > request -> stateful request handler -> choose component and initialize state -> render component > > What is the proper way to do this? > > Thanks, > Camillo_______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Camillo Bruni
Am 2011-04-13 um 17:38 schrieb Camillo Bruni: > Hi, > > 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. > > However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. > > This is how I imagine it should work: > request -> stateful request handler -> choose component and initialize state -> render component > > What is the proper way to do this? Think of this: MyFilter>>#listingOfProject: projectName <GET> <Path: '/{projectName}'> MyComponent new respondRendered with MyComponent>>#respondRendered self requestContext respond: [:response | response contentType: WAMimeType textHtml; nextPutAll: ( WARenderCanvas builder fullDocument: true; rootBlock: [ :root | self updateRoot:root ]; render: [ :canvas | self renderContentOn: canvas ])]. This merely emulates a normal seaside run. But more elaborate versions are possible. So Long, -Tobias_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Olivier Auverlot
On 2011-04-13, at 18:09, Olivier Auverlot wrote: > Hi Camillo, > > I have just published a draft of a tutorial about Seaside-Rest (in french). > > http://www.auverlot.fr/index.php?z=21 > > Hope that could help you. Cool, just had a look at it. Though forwarding to a normal WAComponent is not mentioned. camillo > Best regards > Olivier ;-) > www.auverlot.fr > > > Le 13 avr. 2011 à 17:38, Camillo Bruni a écrit : > >> Hi, >> >> 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. >> >> However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. >> >> This is how I imagine it should work: >> request -> stateful request handler -> choose component and initialize state -> render component >> >> What is the proper way to do this? >> >> Thanks, >> Camillo_______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Tobias Pape
On 2011-04-13, at 18:10, Tobias Pape wrote: > > Am 2011-04-13 um 17:38 schrieb Camillo Bruni: > >> Hi, >> >> 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. >> >> However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. >> >> This is how I imagine it should work: >> request -> stateful request handler -> choose component and initialize state -> render component >> >> What is the proper way to do this? > > Think of this: > > MyFilter>>#listingOfProject: projectName > <GET> > <Path: '/{projectName}'> > MyComponent new respondRendered > > with > > MyComponent>>#respondRendered > self requestContext respond: [:response | > response > contentType: WAMimeType textHtml; > nextPutAll: ( WARenderCanvas builder > fullDocument: true; > rootBlock: [ :root | > self updateRoot:root ]; > render: [ :canvas | > self renderContentOn: canvas ])]. > > This merely emulates a normal seaside run. > But more elaborate versions are possible. Thanks, this is what I was looking for. camillo > > So Long, > -Tobias_______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Tobias Pape
Unless, you're re-using some of the rendering code in multiple places,
you might find it cleaner to simply subclass WAPragmaBasedRestfulHandler to provide a renderer. It could even be implemented with an additional pragma instead of hardcoding: MyFilter>>#listingOfProject: projectName on: html <GET> <Path: '/{projectName}'> <Renderer: #WARenderCanvas> "Or, alternatively just: <Canvas>" html text: 'hello world' You could of course then "html render: anObject", though I'd suggest that you don't really want to use components here, because you have no session and thus no state for them to maintain. You would probably be better to subclass WAPainter if you want to re-use some rendering code in several places. Julian On Wed, Apr 13, 2011 at 5:10 PM, Tobias Pape <[hidden email]> wrote: > > Am 2011-04-13 um 17:38 schrieb Camillo Bruni: > >> Hi, >> >> 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. >> >> However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. >> >> This is how I imagine it should work: >> request -> stateful request handler -> choose component and initialize state -> render component >> >> What is the proper way to do this? > > Think of this: > > MyFilter>>#listingOfProject: projectName > <GET> > <Path: '/{projectName}'> > MyComponent new respondRendered > > with > > MyComponent>>#respondRendered > self requestContext respond: [:response | > response > contentType: WAMimeType textHtml; > nextPutAll: ( WARenderCanvas builder > fullDocument: true; > rootBlock: [ :root | > self updateRoot:root ]; > render: [ :canvas | > self renderContentOn: canvas ])]. > > This merely emulates a normal seaside run. > But more elaborate versions are possible. > > So Long, > -Tobias_______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Camillo Bruni
Am 2011-04-13 um 18:21 schrieb Camillo Bruni > > Thanks, this is what I was looking for. note that a Restful filter is added to a component, so you normally can do self next handleFiltered: self aRequestContext to put the component in charge. So Long, -Tobias _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Julian Fitzell-2
Well I think its currently quite hard to do a nice transition from a normal seaside application using the default, non-readable url to an application with nice urls.
Since extracting the state from the URL is pretty straight forward, though much nicer with the pragma-based approach in REST. However, since I come from the Django world, I expect some simple dispatch logic to map from the URLs to the existing components. But lets try and figure out if it will work ;) camillo On 2011-04-13, at 18:28, Julian Fitzell wrote: > Unless, you're re-using some of the rendering code in multiple places, > you might find it cleaner to simply subclass > WAPragmaBasedRestfulHandler to provide a renderer. It could even be > implemented with an additional pragma instead of hardcoding: > > MyFilter>>#listingOfProject: projectName on: html > <GET> > <Path: '/{projectName}'> > <Renderer: #WARenderCanvas> > "Or, alternatively just: <Canvas>" > > html text: 'hello world' > > You could of course then "html render: anObject", though I'd suggest > that you don't really want to use components here, because you have no > session and thus no state for them to maintain. You would probably be > better to subclass WAPainter if you want to re-use some rendering code > in several places. > > Julian > > On Wed, Apr 13, 2011 at 5:10 PM, Tobias Pape <[hidden email]> wrote: >> >> Am 2011-04-13 um 17:38 schrieb Camillo Bruni: >> >>> Hi, >>> >>> 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. >>> >>> However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. >>> >>> This is how I imagine it should work: >>> request -> stateful request handler -> choose component and initialize state -> render component >>> >>> What is the proper way to do this? >> >> Think of this: >> >> MyFilter>>#listingOfProject: projectName >> <GET> >> <Path: '/{projectName}'> >> MyComponent new respondRendered >> >> with >> >> MyComponent>>#respondRendered >> self requestContext respond: [:response | >> response >> contentType: WAMimeType textHtml; >> nextPutAll: ( WARenderCanvas builder >> fullDocument: true; >> rootBlock: [ :root | >> self updateRoot:root ]; >> render: [ :canvas | >> self renderContentOn: canvas ])]. >> >> This merely emulates a normal seaside run. >> But more elaborate versions are possible. >> >> So Long, >> -Tobias_______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
Oh I see... you're trying to define nice URL entry points that take
the user into full sessions/applications? I'm not sure if that's quite what Philippe had in mind with Seaside-REST (though he may correct me on that). I think I can begin to imagine how something like that might look. But perhaps you could give a high-level description of the various pieces you imagine and how they interact with and link to each other... in other words, what "dispatch logic" do you want to specify? Julian On Wed, Apr 13, 2011 at 5:36 PM, Camillo Bruni <[hidden email]> wrote: > Well I think its currently quite hard to do a nice transition from a normal seaside application using the default, non-readable url to an application with nice urls. > > Since extracting the state from the URL is pretty straight forward, though much nicer with the pragma-based approach in REST. However, since I come from the Django world, I expect some simple dispatch logic to map from the URLs to the existing components. > > But lets try and figure out if it will work ;) > > camillo > > > On 2011-04-13, at 18:28, Julian Fitzell wrote: > >> Unless, you're re-using some of the rendering code in multiple places, >> you might find it cleaner to simply subclass >> WAPragmaBasedRestfulHandler to provide a renderer. It could even be >> implemented with an additional pragma instead of hardcoding: >> >> MyFilter>>#listingOfProject: projectName on: html >> <GET> >> <Path: '/{projectName}'> >> <Renderer: #WARenderCanvas> >> "Or, alternatively just: <Canvas>" >> >> html text: 'hello world' >> >> You could of course then "html render: anObject", though I'd suggest >> that you don't really want to use components here, because you have no >> session and thus no state for them to maintain. You would probably be >> better to subclass WAPainter if you want to re-use some rendering code >> in several places. >> >> Julian >> >> On Wed, Apr 13, 2011 at 5:10 PM, Tobias Pape <[hidden email]> wrote: >>> >>> Am 2011-04-13 um 17:38 schrieb Camillo Bruni: >>> >>>> Hi, >>>> >>>> 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. >>>> >>>> However so far I could not figure out how I should render a component from within a WAPragmaBasedRestfulHandler method. >>>> >>>> This is how I imagine it should work: >>>> request -> stateful request handler -> choose component and initialize state -> render component >>>> >>>> What is the proper way to do this? >>> >>> Think of this: >>> >>> MyFilter>>#listingOfProject: projectName >>> <GET> >>> <Path: '/{projectName}'> >>> MyComponent new respondRendered >>> >>> with >>> >>> MyComponent>>#respondRendered >>> self requestContext respond: [:response | >>> response >>> contentType: WAMimeType textHtml; >>> nextPutAll: ( WARenderCanvas builder >>> fullDocument: true; >>> rootBlock: [ :root | >>> self updateRoot:root ]; >>> render: [ :canvas | >>> self renderContentOn: canvas ])]. >>> >>> This merely emulates a normal seaside run. >>> But more elaborate versions are possible. >>> >>> So Long, >>> -Tobias_______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Camillo Bruni
as reference, for airlfowing we are: 1. creating a normal session 2. remembering the #initialRequest: 3. presenting the login in (but only if the visit doesn't have a valid login cookie) 4. if logins ok, the service creates the main component and receives (a clone of) the initial request 5. it gets parsed and delegated until it reaches the component with relevant responsibility (if not degrades gracefully). Hint: the subcomponets are created lazily. Nothing fancy, no sophistication nor generic solution but it gets the thing done intuitively, without complications and clean code o/ On Apr 13, 2011, at 12:38 PM, Camillo Bruni wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
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.
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. 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. So for instance in the following (non-origin related) example, /country/Switzerland/city/Biel /country/Switzerland/languageRegion/Romandie , 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. 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. 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). Best regards, Camillo On 2011-04-13, at 20:49, Sebastian Sastre wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
Seaside wasn't originally meant to take advantage of convention over configuration (like mapping urls to state), actually I would say is quite agnostic (so it goes beyond that principle). Of course that has a price (that is surprising you in the wrong way) but if you put it in the right context it gives you more freedom. So? You need to convert that problem in a non-issue with design. The key is in the way you make the delegation. And as you said it would be nice that "countries" know country stuff and regions, well.. region stuff. So you have parents being responsible for what's best for their children :) That's the natural Law :) You have one of the most powerful and fast prototyping tools in the world for doing that, so play around on how to parse it until you get it. As reference I can tell you that we use the persisted object (model.) For instance when we receive an url with commentId=blahblahblah we search blah blah blah and that comment (model-object) is related to something that allows us to deduct which component to instantiate. In our case that's what happens to answer "What is a conversation? a job? an estimate? a payment?" The "state" is the state in which it comes from the odb and we made everything to get instantiated lazily maching the state of the model by design. When a model is set we are sure the component will represent well the state of the model. That's how we converted that problem into a non-issue. On Apr 13, 2011, at 4:27 PM, Camillo Bruni wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Camillo Bruni
Am 13.04.2011 um 21:27 schrieb Camillo Bruni: 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. 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. 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. Norbert
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
In reply to this post by Julian Fitzell-2
2011/4/13 Julian Fitzell <[hidden email]>:
> Oh I see... you're trying to define nice URL entry points that take > the user into full sessions/applications? I'm not sure if that's quite > what Philippe had in mind with Seaside-REST (though he may correct me > on that). Well no, but yes :-) Whereas the problem is not about REST it is about binding/injecting request attributes which is what Seaside-REST does. One thing that Seaside currently does not allow you to do is easily build is an application with stateless landing pages and stateful components kicking in later. I'm not sure Seaside-REST is the right tool for this since it does not do arbitrary injection, it just injects into the handlers methods. Maybe a better solution would be to build two applications and the stateless one forwarding to the sateful one at one point. That still leaves the problem of writing the stateless one and initializing the stateful one though. So something similar to Seaside-REST but different could be the way to go. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering Component in a WAPragmaBasedRestfulHandler
|
|
I somehow solved the problem now by relying on the pragma evaluation of REST.
So I simply use a normal Root component and internally overwrite the initialRequest: method to find the proper handling method with REST. The handling method initializes (lazily) the current view and assigns it to an instvar. In the renderContentOn: I simply forward to the currently active view. This way is somewhat a compatible transition from a normal seaside application, since you could use the helper methods there as well... So for my solution the REST functionality should be encapsulated into a single helper object. However I am still figuring out a nice way to forward parts of the url to a subcomponent to avoid many initialization methods on the root component. cheers camillo On 2011-04-17, at 20:34, Philippe Marschall wrote: > 2011/4/13 Julian Fitzell <[hidden email]>: >> Oh I see... you're trying to define nice URL entry points that take >> the user into full sessions/applications? I'm not sure if that's quite >> what Philippe had in mind with Seaside-REST (though he may correct me >> on that). > > Well no, but yes :-) Whereas the problem is not about REST it is about > binding/injecting request attributes which is what Seaside-REST does. > One thing that Seaside currently does not allow you to do is easily > build is an application with stateless landing pages and stateful > components kicking in later. I'm not sure Seaside-REST is the right > tool for this since it does not do arbitrary injection, it just > injects into the handlers methods. > > Maybe a better solution would be to build two applications and the > stateless one forwarding to the sateful one at one point. That still > leaves the problem of writing the stateless one and initializing the > stateful one though. > > So something similar to Seaside-REST but different could be the way to go. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |