[Seaside] Re: Seaside and REST
philippe.marschall at gmail.com
Thu Mar 29 22:46:30 UTC 2007
2007/3/30, Andreas Raab <andreas.raab at gmx.de>:
> Philippe Marschall wrote:
> > Anchors are GET, always. That has nothing to do with Seaside but with
> > HTML. Forms are default POST and GET if requested. Same as in HTML.
> > I really fail to see the problem there, Seaside behaves exactly like
> > HTML which is not surprising since it uses HTML.
> Thanks. I think I got a little bit taken away with the whole "it's got
> nothing to do with urls/http/html" speech ;-) Since I don't know the
> whole of W3Cs specs at heart it wouldn't have surprised me to find out
> that there is some magic hidden inside seaside that makes it happen.
How did Joel put it, leaky abstractions? ;)
You certainly need to know html for doing Seaside. You need to know
CSS or that you don't know CSS like in my case.
> BTW (and this is not a criticism of Seaside but rather the docs) there
> is quite a bit of confusion for me about what exactly a component is
> expected to do and what not. Like: the component shouldn't worry about
> pages but it needs to worry about forums. Having the responsibilities
> stated somewhere would help me getting a better feel for understanding
> how to structure seaside apps. There are various other areas (the use of
> styles and css, or meta tags for example) that I'm not at all sure where
> the responsibility lies.
A component is responsible for generating a part of the html of a
"page". This includes forms, since they are part of html (note that
you must not nest forms, forms really suck in html). The (visible)
part inside the <body> is generated in #renderContentOn:. The part in
the <title> is generated in #updateRoot: (cerate your metas here).
CSS depends on your needs. There are about three different ways for
different situations. In general you assign the correct classes and
ids to your html elements and the CSS comes from "somewhere" outside.
You will have to write your CSS by hand (or let it write) Seaside
doesn't help you there. It just gives you a choice where to put it.
We suck at documentation and getting started. We know that and are not
proud about this. We know the store example sucks. What would help are
easy ways to turn mails like this into useful documentation. And of
course if people help with documentation ...
> Any good places to read up on? (where is the Seaside book when you need
> it ;-)
Seaside mailinglist ;)
Ramon has some good blog posts, more can be found at:
> - Andreas
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside