[Seaside] Rendering Component in a WAPragmaBasedRestfulHandler

Sebastian Sastre sebastian at flowingconcept.com
Wed Apr 13 20:00:00 UTC 2011


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.

sebastian

o/


On Apr 13, 2011, at 4:27 PM, Camillo Bruni wrote:

> 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:
> 
>> 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
>> 
>> sebastian
>> 
>> o/
>> 
>> 
>> 
>> On Apr 13, 2011, at 12:38 PM, Camillo Bruni wrote:
>> 
>>> 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
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20110413/1278ed71/attachment-0001.htm


More information about the seaside mailing list