Re: IOWA troubles (was Re: choice of HTML templating system)

Thomas Hurst wrote:
> * Julian Fitzell ([e-mail]) wrote:
>>Thomas Hurst wrote:
> Well, the thing is, what's the point in serving content if the one
> way of specifying it's location is a meaningless jumble of characters?

Well, there's still a point... it just means you can't bookmark it as 
easily :) Seriously, though, this is a problem that we try to address as 
  well as we can. The squeak rewrite of Iowa (called Seaside) changes 
the URI to include an /action portion.  We use this as follows:

Link in pages would go to a URI like 
http://www.server.com/calculator/1/1/act

and that would perform whatever actions are associated with that link. 
Then it forwards the browser to:

http://www.server.com/calculator/1/2/view

which would display the results.  The nice thing about this is that when 
you hit the back button, you go back to /calculator/1/1/view not 
/calculator/1/1/act which means that you don't have the "double 
submission" problem that you can get with other systems.

Anyway, it's also used to provide /inspect and /profile actions which 
allow you to inspect the page objects and do profiling respectively. 
These action are easily added so you could add actions that jumped to a 
particular page.  This might help you somewhat though you would still 
have to start a session first.


> Well, concider I want to serve fairly static content; collections of
> articles etc, with navigation elements built up from metadata from some
> backend that may do fancy things like versioning, or whatever; a URI
> schema for a one-time-object-instance you can only recreate by going
> though a set of links from the start of the site each time isn't very
> optimal for that sort of layout.  Even things like weblogs are better
> off having URI's like /article/yyyy/mm/dd/id or so.
> 
> Sorry, I haven't looked hard enough at iowa to work out how things like
> this work in it - can URI schemas like that be supported using it?

Not really.  I mean I guess there's nothing to stop you parsing the end 
of the path instead of the parameters to get data but it's much less 
generic.

>>So while you could shorten the URI a little it still needs to contain
>>some numbers to make things work smoothly.
>>
> 
> What about if you're just serving content and don't need to worry about
> state (much)?  Bog standard URI schemes which contain a path to a
> resource are really all I want

Well, then you probably don't want Iowa for that application.  The 
benefits of Iowa are really related to the transparency of state 
management and the HTTP request/response mechanism.  If all you are 
doing is displaying some rendering of database data, Iowa is not 
necessarily the best fit.

The thing is, the contents of a page (like even which components are 
being displayed) is totally variable each time the page is viewed 
(depending on the state of any number of variables) so you can't just 
specify the page name in the URI, you really need to specify a value 
that uniquely identifies that particular "instance" of a page view.  The 
decision of what action to perform is made by the object that you are 
viewing at the time you perform the action (as opposed to some other 
page that you are submitting to as in PHP, ASP, etc.) so you have to get 
back to that same object before you can figure out what action to do.

Does that make any sense?

To look at your example above, I can't just go to /article/yyyy/mm/dd/id 
because I'm not just viewing that article, I'm viewing that article 
with, for example, word wrapping turned on, a setting that only displays 
30 lines at a time with a link to the next 30 lines, etc, etc... there's 
too much state to pass around in the URI, and if you did it would be 
even uglier than it is now.

One solution is to just store all this information keyed by a session 
ID, but then when you hit the back button things get screwed up.  With 
Iowa, you can hit the back button and choose another link and program 
flow will continue as if you had clicked that link in the first place. 
The variables will all have the values that they had when you were in 
that page the last time (obviously you can explicitly store data in the 
session that represents more "global" settings).  This backtracking 
behaviour makes for a much safer experience when using a web 
application, IMO.

Note we have added several different backtracking configuration options 
in Seaside, and are considering having a set of pages marked as a 
transaction so you can backtrack to before that transaction began but 
not into the middle of it.

>>If you really cared about the URI's you could probably have a frameset
>>with just one frame or something and put the iowa page in the frame.
>>Then browsers wouldn't show the URI changing, they just show the URI
>>of the frameset - I think.
>>
> 
> Sorry, I'm afraid you're going to burn in the fiery pits of hell for all
> eternity for suggesting something 10x worse than messy URI's ;)

My god, you're right... I can't believe I actually advocated frames... 
where's that soap, I feel dirty! :)  Actually, I didn't really 
*advocate* it, just pointed out that you could do it if you cared about 
the URI's :)

I notice I deleted your comment about security which I meant to reply 
to.  I agree this is a problem.  We intend to add support for 
authentication which would help a little (for expired sessions, etc), 
and not showing the session-id in the URI (ie. putting it in a cookie) 
also helps at some level.  We've also thought about storing the IP 
address of the user and only allowing connections to their session from 
that IP.  Obviously all these items have pros and cons and need to be 
configurable.  If you have any other ideas that would help please 
mention them. We haven't really adressed this yet but we should.

In closing, I should reiterate that Iowa is great for designing web 
*applications* but not so great for desiging web *sites*.  I keep 
thinking we should be writing our web site using Iowa as a proof of 
concept, but I don't think it works very well - for the exact reason 
that you want to be able to bookmark it... it isn't really an 
application, just a bunch of static, or quasi-dynamic content.

Phew, long message, hope it clarifies some,

Julian

-- 
[e-mail]
Beta4 Productions (http://www.beta4.com)