Andrea Aime wrote:
> Andrea Aime ha scritto:
>
> It's interesting to see how Hudson does its own plugins:
> http://weblogs.java.net/blog/kohsuke/archive/2006/08/hudson_140_and.html
>
> It's a little sad to see that the author ended up using a view
> technology that has no tool support, and created his
> own web framework (https://stapler.dev.java.net/what-is.html), since he
> could not find anything that suited his way of doing things.
Well, I don't want to sound harsh, but I find a even more sad to rely on
JSP and servlets: let me start from kohsuke's use case...
<<Even in the web app it's pretty convenient to overload views --- you'd
want to show a different page for displaying book details and CD
details. So depending on the kind of product 513, you'd want to use
different JSPs.
<snip/>
Once you get a "primary key", you still have to get to the
corresponding data from JSP, and when you have multiple JSPs that work
on the same data (perhaps you have createProduct.jsp and
checkProductInventory.jsp or something), then the said logic needs to be
on all such JSPs>>
...and let me show how this could be done in done in Cocoon (just off
the top of my head, apologies for syntax errors):
A bit of URI matching (NOTE: "{1}" returns the value of first "*"
wildcard character contained in the matched-URI's template):
<match template="product/*">
<call function="showProduct">
<parameter name="productId" value="{1}"/>
</call>
</match>
<match template="product-*.html">
<generate type="jx" src="product-detail-pages/product-{1}.jx">
<serialize>
</match>
(NOTE: let's suppose details-cd.jx creates an HTML page for a CD, while
detail-book.jx creates one for a book).
A bit of Flowscript (essentially server-side Javascript, though Java may
be used as well):
import com.mycompany.inventory.Product;
function showProduct() {
var prod= Product.getById(cocoon.parameters.productId);
cocoon.sendPage("product-" + prod.getTypeName() + ".html",
{product : prod}):
}
(NOTE: let's suppose the Product Java class implements the business of
getting
a product out of the database given its id).
The page flow goes on like this:
1) The user requests the "product/513" URI.
2) The requested URI is matched by the first match and routed to the
showProduct() Flowscript function along with the productId parameter
(which is contained the last part of the URI, RESTful-style).
3) The showProduct() function collects the product's data and requests a
page depending on the type of the product (passing the product bean along).
4) The requested "product-cd.html" (or "product-book.html") URI is
matched by the second match and a product type-specific HTML page is
produced (via JX, a simple template languages) getting data from the
given product bean.
You may clearly see the different layers of the application:
1) URI matching and template pages: View.
2) Flowscript (Javascript or Java): Controller
3) POJOs (like Product): Model.
Better than Stapler and JSP, isn't it ? No coupling between files on
disk and URIs, clear separation between pages and actions.
Regards,
P.S.
Actually, if the matter is only about matching Java Classes to URIs and
doing some CRUD, I think RESTlet may be even more helpful.
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
