I read Florent's suggestion of URL Rewriting and IMHO I think its a
great idea, if used carefully.
In the app I'm imagining ... ("desiging"). The App server portion will
only return HTML,
and the XDBC portion will only return more raw XDM values.
Thus there is no need for parity between them.
There is no need for an XDBC client to access the same scripts as a Web
client.
In the Web client case, most likely a browser, but could be a REsTful
server, there is value in a cleaner URL such as
http://myhost.com/page?arg
which if I used url-rewriting could go to
/html/page.xquery?arg
XDBC clients, being more programer-centric would have no problem doing
something like
http://myhost/modules/query_for_special_stuff.xquery
and pass in bound variables.
ReSTFUL servers are a overlapping case, where they are programatic
(hence more flexible in using URL's) but may want XML not HTML ... but
with a simple rule I could redirect them to specially designed Rest
services like
http://myhost/rest/query?arg
-> /rest/query.xquery?arg
I actually think this is a clean way to seperate concerns.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Geert
Josten
Sent: Tuesday, December 15, 2009 2:23 PM
To: General Mark Logic Developer Discussion
Subject: RE: [MarkLogic Dev General] Towards a more modular app
architecture...
Just to make sure all readers can understand:
MVC is indeed an appropriate pattern, and a nice example of Separation
of Concerns as well. The Model is supposed to take care of the data
access (including data business rules), the View of the data
presentation (typically on a user interface), and the Controller adds
application logic, translating user input into Model or View changes.
The original MVC pattern also describes particular communication
channels between these three parts. Users interact with views.
Controllers observe views and act upon user input, perhaps by initiating
Model changes. Views again observe models for changes, to update their
presentation. It is not that easy to work with observers in web
applications, so it is not uncommon to have Controllers 'delegate'
between Views and Models (like in 2/ below), but apart from that it is
still useable.
2 cents of my own:
I am not sure I would put URI rewriting in the middle like that. The
main reason is that URI rewriting doesn't work with XDBC. It could mean
that you have to come up with alternative logic to work with XDBC app
servers. I tend to prefer doing things only once and in one way only..
(you can call me lazy.. :-P)
I am not sure either that Model and View would be that difficult to
distinguish. A Model can be reused by anything else, meaning any kind of
View, any kind of Controller, and perhaps even other applications or
logic. Everything concerning presentation is part of Views. This should
make clear which layer belongs where. I could easily imagine though
there is functionality that could be shared among different Views, but
that doesn't make it part of the Model.. ;-)
No offence, it was valuable to mention MVC, good pointer!
Kind regards,
Geert
>
Drs. G.P.H. Josten
Consultant
http://www.daidalos.nl/
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel.: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
http://www.daidalos.nl/
KvK 27164984
De informatie - verzonden in of met dit emailbericht - is afkomstig van
Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u
dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te
verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Florent Georges
> Sent: dinsdag 15 december 2009 17:54
> To: [email protected]; General Mark Logic
> Developer Discussion
> Subject: Re: [MarkLogic Dev General] Towards a more modular
> app architecture ...
>
> 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
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
