Berin Loritsch wrote:
<snip what="interesting explanation"/>
Where CRACK is Better
---------------------
Ruby on Rails is highly HTML centric. That's ok because 80% of all
web applications are HTML centric. However, we can leverage a
convention that they started in a more powerful way. In addition to
the normal View conventions, Rails also has the concept of a layout.
You can apply the same layout to all the views in your application.
Now, remember that I said that Rails doesn't support extensions
(.html, .png, etc.). We can set up a set of layouts that are
essentially the finishing pipeline for the application. By specifying
a generic page markup we can provide default layouts, but the
convention would work like this:
* The layout has a base name such as "site" which is how the layout
would be specified in the controller.
* The XSLT layout naming convention would be {name}2{ext}.xsl, and we
would automatically select the serializer mapped to the {ext} name.
- Example: login/index.html using the "site" layout would transform
the standard markup using the "site2html.xsl" file and use the "html"
serializer.
- This allows us to also render a "site2pdf.xsl" using the "pdf"
serializer for /article/show/3.pdf
Funny, I just wrote something similar for my current project (simplified
as it's a form pipeline):
<map:match pattern="view-*">
<map:generate src="{1}.jx"/>
<map:select type="resource-exists">
<map:when test="style/page-{1}.xsl">
<map:transform src="style/page-{1}.xsl"/>
</map:when>
<map:otherwise>
<map:transform src="style/style.xsl"/>
</map:otherwise>
<map:serialize/>
</map:select>
</map:match>
What that means is that all pages are using the common "style.xsl"
stylesheet except if a specific "page-xxx.xsl" file exist. It then
overrides the common styling.
Define this selector and transformers snippet as a virtual component and
you have a transformer that uses convention over configuration and yet
allows people to add some specific styling if ever needed.
Changes to Cocoon
-----------------
In order to support something like this, we don't have to make
fundamental changes to Cocoon. In fact, all we have to do is provide
an alternate Sitemap implementation that uses reflection to find the
controller class and build the pipeline based on the view source, the
layout location, etc.
We can do that right now with flowscript. Something along these lines:
<map:call function="frontend"/>
function frontend() {
var path = cocoon.request.requestPath;
var elements = split(path);
if (this[path[0]]) {
this[path[0]]();
}
if (!cocoon.redirector.hasRedirected) {
cocoon.sendPage("view-" + path);
}
}
If the controller function does not exist, or if it did not explictely
sent a page, then we call the view.
One of the things that would also help _emensely_ is to automatically
generate a 404 return response if there is no Controller/Action
match. There are other things that will help in the process, but I
believe this is a much more usable way to get baptised into
Cocoon--and still leverage its power. Because we would be using
convention to wire together an application, we have the power to even
build in some normal conventions for being browser aware by default.
If the end client's browser is smart enough to handle client side
styling then we can let it happen--with no more effort required by the
developer.
Oh, and one more thing: we default to UTF-8 as the default encoding
all the way through. There are issues with the ESQL logicsheet
introducing encoding errors, and a few more other locations. Just
because much of the commercial industry seems to be ignoring
internationalization does not mean we should follow they poor example.
What do you think? Rosy picture? BTW, I only used the name CRACK as
an eye catcher--I'm not expecting the final product to be named that.
I love it. Let's call it Crackoon :-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
