Why is Borges (or Seaside) coupled to an html/browser interface?
It seems that the Component model (composable logical ‘panes’ with
application logic) and the modelessness and free ‘Back’ button
functionality, could both be useful outside the context of an HTML browser.
It seems that Components, rather than generating HTML through a renderer,
could generate some kind of logical ‘Interactor’ descriptions. Different
Renderers could then map this differently:
HTML renderer:
map to (a part of) an html page, or to some sequence of (part of)
html page
I would guess it’s mostly because HTML is the most obvious and immediate
use so that is where the effort has gone.
I’ve thought a lot about the feasibility of using Iowa as a content engine
for non-HTML content. In my case, for use as an engine to generate
on-demand email with custom content. In a lot of ways it seems like a
good fit. From what I know of Borges/Seaside, the same goes for them,
only probably moreso because there is that concept of a renderer that
actually produces the content. Borges/Seaside is not so well suited to
the task of generating single chunks of dynamic content, but I think
they’d be pretty well suited to the kind of thing you are talking about.
Use a different renderer layer and the web/browser based application could
instead be a GUI application in its own right?
Eric? Avi? Thoughts?
Kirk Haines
···
On Sat, 3 Apr 2004, Its Me wrote:
Why is Borges (or Seaside) coupled to an html/browser interface?
It seems that the Component model (composable logical ‘panes’ with
application logic) and the modelessness and free ‘Back’ button
functionality, could both be useful outside the context of an HTML browser.
Why is Borges (or Seaside) coupled to an html/browser interface?
···
On Sat, 3 Apr 2004, Its Me wrote:
It seems that the Component model (composable logical ‘panes’ with
application logic) and the modelessness and free ‘Back’ button
functionality, could both be useful outside the context of an HTML browser.
It seems that Components, rather than generating HTML through a renderer,
could generate some kind of logical ‘Interactor’ descriptions. Different
Renderers could then map this differently:
- HTML renderer:
- map to (a part of) an html page, or to some sequence of (part of)
html page
- Other UI renderer:
- different mapping e.g. to native widgets
A little bit like XForms.
I’m really only a Seaside dabbler (and one with a pretty bad memory,
unfortunately), but I don’t think that Seaside itself is hard-wired to
HTML. Conventionally, each component’s #renderContentOn: method accepts a
WAHTMLRenderer, but I don’t know of a reason that you couldn’t pass in
some other kind of renderer of your own making.
I seem to remember someone (maybe it was Avi’s RubyConf 2002 talk)
demonstrating the same application working as a command line app and as a
web app. I might have made that up, though.
Why is Borges (or Seaside) coupled to an html/browser interface?
Its not, really. I asked a related question on the Seaside list in
the course of my porting Seaside to Borges, and when you get into the
guts, you find out that Seaside is a bunch of well-factored
bolt-together pieces. (Borges uses the same approach.)
The Renderer itself is actually two pices, an HtmlBuilder and an
HtmlRenderer. The Builder only knows about HTML widgets. The Renderer
knows about callbacks and form processing.
It seems that the Component model (composable logical ‘panes’ with
application logic) and the modelessness and free ‘Back’ button
functionality, could both be useful outside the context of an HTML browser.
The only thing stopping you from using it outside of an web server is
the render_on methods being written as HTML-centric.
It seems that Components, rather than generating HTML through a renderer,
could generate some kind of logical ‘Interactor’ descriptions. Different
Renderers could then map this differently:
You can take Seaside apart kinda like Legos, the problem is finding out
where the edges of the pieces are
HTML renderer:
map to (a part of) an html page, or to some sequence of (part of)
html page
