In terms of app architecture XQMVC is definitely worth a look: http://code.google.com/p/xqmvc/
And then there's my take... http://dubinko.info/blog/2009/11/29/model-endpoint-template/ -m On Dec 15, 2009, at 8:54 AM, Florent Georges wrote: > 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 _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
