scalawithsails-devl Mailing List for Scala with Sails
Status: Pre-Alpha
Brought to you by:
dpp
Menu
▾
▴
scalawithsails-devl — Discussions about development, etc. related to Scala with Sails
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
|---|
|
From: David P. <dp...@at...> - 2006-12-12 19:47:00
|
Folks,
I've put version 0.0.2 of Scala with Sails up in the SourceForge SVN
repository.
The latest version has the following features/bug fixes:
* Compiles correctly with Scala 2.3.1
* Migration to using Option/Some/None instead of 'null'. Thanks to
Burak for helping me understand the Option/Some/None paradigm
* Support for serialized primary keys
* Support for complete CRUD operations (Create, Read, Update,
Delete) on mapped DB objects
* A complete CRUD example (you can create, update, and delete
example Fish)
* I've validated the code against MySQL and PostgreSQL
I've also created two mailing lists:
sca...@li... -- This mailing list is for
SwS users who have questions about developing apps using SwS. I'm not
expecting much traffic on this list early on... :-)
sca...@li... -- This mailing list is for
SwS developers or folks who have ideas that they want to see implemented
in SwS.
The SwS home page is available at http://scalawithsails.com and there's
link to a live example as well as the SourceForge project.
Thanks to Burak, Dave Webb, and Philipp Schmidt for ideas, suggestions,
and code!
We're closer to building a wiki with SwS.
Thanks,
David
--
Blog: http://blog.lostlake.org
|
|
From: Dave W. <da...@xi...> - 2006-12-12 13:24:24
|
>
> I'm currently noodling "page composition"... basically the right way to
> specify what components go on a page and then how they ordered into the
> resulting HTML (there's a CSS related issue here, but I'm punting on that
> for right now.)
>
The basic pattern I tend to go for to compose markup is a simplified xslt.
Generate xml, then transform it using a decorator. This might be a good
starting point conceptually.
e.g.
myxml =
<decorate template="mytemplate">
<content name="left-bit">/*generate left markup*/</content>
<content name="right-bit">/*generate right markup*/</content>
</decorate>
mytemplate =
<html>
<table><tr>
<td><value-of select="content[name='left-bit']</td>
<td><value-of select="content[name='right-bit']</td>
</tr></table>
</html>
In addition
1. myxml can explicitly include component markup,
e.g.
<div><include component="mycomponent"></div>
2. decorators can be based on higher decorators
e.g.
mytemplate =
<decorate template="pagetemplate">
<table><tr>
<td><value-of select="content[name='left-bit']</td>
<td><value-of select="content[name='right-bit']</td>
</tr></table>
</decorate>
3. decorate can appear anywhere in the markup. i.e. you can have a template
to compose the whole screen, or you can have a template just to put a border
around something
The nice thing about using Scala is that (hopefully) the transforming markup
e.g. <value-of...>, <component..>,etc can be replaced with simpler non-xml
syntax, e.g. {leftBit}, so the only markup left in the code is html
For a given view class, maybe we could mixin templates/components using
traits? Anyhow, the idea is to use Scala's DSL flexibility to express these
transforms to avoid the bulkiness of xsl
I guess the challenge here is to keep it really simple, so you can get in
there and write code straightaway without frst having to configure x-billion
xml files... would be nice to be able to get a simple page up and running
(like the example Index class), then incrementally build components and
decorators as a natural refactoring process in the Scala code.
As for how this fits in with other aspects of components, like a component's
behaviour (handling ajax, the back button, Faces-style component lifecycle,
etc) I don't know.
(Seems to me sometimes that a lot of ideas inspired by the genesis of xml
(like xslt) got lost along the way in a sea of pointy brackets. Maybe the
simplicity of Scala can be the cure)
> The moving parts in my mind are:
> - The components that exist on a page (e.g., the search box, the menu,
> the "main" part, etc.)
> - The order in which the components are laid out in the fully rendered
> HTML page
> - The "decoration" around each component (although the need for
> decoration is lessened with CSS)
> - How the component is rendered for a partial page render (e.g., AJAX or
> Comet update)
>
> I don't know if there should be a meta-view and/or meta-controller
> over-laid on the existing Rails-style controller/view paradigm. Perhaps
> this stuff should all just be infinitely layered so a view can be a
> meta-view of other views, etc. and using your paradigm, you'd have a
> bunch of decorators and content and the "output" of one could be piped
> into another.
>
> Sound reasonable?
I definitely like the idea of infinitely layered views. That's something I
know will save me effort.
As for the controllers.. the controller:
a) responds to the request by changing the model (updates db, etc)
b) selects the view, generates data for the view, forwards to the view.
(a) doesn't need to be layered.. it just corresponds to an action (e.g.
deleteitem?id=4), but (b) does need a sense of the layering of the view it
calls.
So I don't know whether the controllers need to be layered as such, for this
issue at least, altho that might be the best way to achieve (b).
Perhaps each view/decorator could define its own default data generator,
that could optionally modified by the controller? So, for a listbooks view
decorated with pagetemplate, the listbooks controller would generate the
list of books, whereas the controller would delegate to pagetemplate's own
default generator to get standard header data like the number of books sold
today, etc.
Haven't other systems addressed the issue of layered pages in MVC before?
|
|
From: David P. <dp...@at...> - 2006-12-11 21:56:18
|
Dave,
There was no code attached, but this is a really good idea.
I'm currently noodling "page composition"... basically the right way
to specify what components go on a page and then how they ordered
into the resulting HTML (there's a CSS related issue here, but I'm
punting on that for right now.)
The moving parts in my mind are:
- The components that exist on a page (e.g., the search box, the
menu, the "main" part, etc.)
- The order in which the components are laid out in the fully
rendered HTML page
- The "decoration" around each component (although the need for
decoration is lessened with CSS)
- How the component is rendered for a partial page render (e.g., AJAX
or Comet update)
I don't know if there should be a meta-view and/or meta-controller
over-laid on the existing Rails-style controller/view paradigm.
Perhaps this stuff should all just be infinitely layered so a view
can be a meta-view of other views, etc. and using your paradigm,
you'd have a bunch of decorators and content and the "output" of one
could be piped into another.
Sound reasonable?
Also, I've just started an SwS developers mailing list (I've cc'ed
this message to that mailing list.) Please subscribe (send an email
with subject 'subscribe' to scalawithsails-devl-
re...@li...) so we can continue the discussion on
the list.
Thanks,
David
On Dec 10, 2006, at 5:02 PM, Dave Webb wrote:
> Hi David,
>
> It's been fun following what you're doing with SwS so far.. don't
> understand the half of it, but I'm sure I'll learn loads trying to
> keep up.
>
> I've attached a webapp demonstrating a simple pattern for
> templating for jsps usng taglibs.
>
> <decorate page="mydecorator.jsp">
> <put name="my-content">content to be decorated</put>
> </decorate>
>
> I thought this pattern might be useful as an integral part of SwS...
>
> e.g. for a view like
>
> def index = {
> <html> //... banner etc
> <table><tr>
> <td>left content</td>
> <td>right content</td>
> </tr></table>
> // ...
> </html>
> }
>
> .. it would be cool to have a simple mechanism to decorate the
> content, you could just define:
>
> def index = decorate with myDecorator {
> <left-content>this is left content</left-content>
> <right-content>this is right content</right-content>
> }
>
> .. and have the decorator do the rest
>
> .. or umm something like that.. maybe with a neater scala/DSL way
> of doing things.. it's a bit like generating specific content in
> xhtml fragments, then using transformers to generate the output.
>
> Mentioning it because for me having a simple intuitive way to
> template a site, integral to SwS, would be a great time saver.
>
> Cheers,
> Dave Webb
|
