Lee, David wrote:
Hi David,
> Any other suggestions ?
I see a web application in MarkLogic as any other web
application. So I like to apply the MVC pattern. So to name
concrete things:
1/ I use the URI rewriting support to dispatch the original
request to a controller (for instance myapp/* to the myapp
controller, myapp2/rest/* to the myapp2 REST controller
and other myapp2/* to the myapp web controller).
The problem is that the original request (especially the
original request path) is not passed to the module
redirected to. The later see the exact same request it
would see if called directly. If you know you never use
query parameters, you can pass infos from the original
request as query params, in the URI rewriter;
2/ there can be several kind of controllers, most notably
traditional "web" controllers (returning an HTML view to
be view by a human on a desktop browser), REST controllers
(getting and returning XML) and binary files (returning a
binary file from a BLOB in the database).
But all do the same basic things: computing a target from
the initial request path (aka the model), invoke it (to
get the actual model value), then applying a view to its
result;
3/ the view can be nothing or very simple (as in the case for
a binary file, it can do nothing or just set the result
code and Content-Type), or be more complex, like a
complete transform pipeline. I look forward to the next
version of ML, to be able to use XSLT here, and on a
subsequent version to even use a complete XProc pipeline
here ;-)
The limits between the model and the view are not so
clear. For instance, you can define several layers: the
business entities (aka what you have in your database:
invoices, users, catalogs, items, etc.), a widget system
(components to add, select, delete entities), an abstract
page layout (made up of paragraphs, emphasys, lists,
titles, etc.), the actual HTML of the page core, then the
complete HTML (the core augmented with menus, header,
footer, etc.)
A model will typically return elements of the lower layers
(entities, or an abstract page), but whatever it returns,
that will go through the pipeline to transform it to the
actual final, complete HTML page...
Each step / layer / component / page can then be (more) easily
tested, and evaluated from the outside of the server.
What misses now in XQuery is a solid description of how an HTTP
request is mapped and dispatched to a "component" (here an XQuery
main module). If we had that, it would be possible to write
frameworks implementing those concepts as third-party frameworks
(say like Struts for Java EE back 10 years ago). Now, you have
to write all that boilerplate code yourself.
Just my 2 cents...
Regards,
--
Florent Georges
http://www.fgeorges.org/
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
