Access to Java Objects in the Container

[knuckleswanny]

How do I talk to the request, response and session objects? We are inside of the Tomcat container at runtime so all of those things are available, are there any handles to them?

[antun]

Hey knuckleswanny

If you're talking about a quick way of getting to the HTTP headers, then have a look at the HTTP data source example: (httpdata.lzx).

Is that what you mean, or do you really need the Java objects themselves?

Take care,

Antun

[knuckleswanny]

I was actually thinking about having actuall access to the objects themselves. There is probably something that I'm missing but I'm thinking about a couple of different things. One is using laszlo as the view layer of an MVC app. For me, the ui is the smallest part of any application. I was hoping to hook laszlo up to some industrial strength code on the back end and not use too much scripting. I just want a little more control of the objects that I'm using.
Thanks for the timely reply by the way Antun.

[antun]

Hey knuckleswanny

We're going to try to get you an example to achieve what you want, though it's not like we have any straightforward APIs.

One thing you may want to think about is that being able to do scripting on the client is a huge benefit; it helps avoid needless server round trips.

Take care,

Antun

[knuckleswanny]

I totally agree that scripting on the client side is very handy but it only goes so far.
As an example, here's something that I've done recently. For security purposes, the client requirement needed auditing of a specific users actions. After analysis I decided that creating a context object in the session that stored a users id, a unique id that I generated using java.rmi.server.UID and the session id, I could gather info about the users actions and store unique session info in the database for reporting purposes. Kind of over kill but the job was for a financial institute.

[antun]

You could achieve all this in the runtime of the client, and then sending occasional updates to the server, or use a persistent connection to do so.

In fact you could build an event-based system to track exactly where/what was clicked and so forth.

-Antun

[knuckleswanny]

But that defeats the purpose of using the MVC architecture. Then you have a situation where the view and the model are blurred creating a maintenance nightmare. Even if you are creating classes that execute in the clients runtime you are still pushing the model out to the client attached to view. Now we get into the semantics of the issue, lol. Can webapplication development truly be MVC, smalltalkers and purists say no, I am not adverse to a small amount of logic in my view but only in so far as it addresses view issues. For example dynamic code to change the appearance of some aspects of the pages or some logic that controls access to various widgets on a page. I don't like to expose the fundamental system to the view though. When the view knows too much about the model and or the controller then the coupling of the app becomes too tight and maintenance becomes problematic. I don't want to have to change code in three different places for one minor change. Am I making sense or just rambling now...

Thanks for putting up with all of this Antun.

[jtang]

Hi knuckleswanny,

I totally agree - using MVC to separate layers of your application is often a wise approach, especially for larger enterprise web apps. Abstracting data, business logic and controllers from the presentation layer can go a long way toward keeping app development manageable and extensible.

I've found that the Laszlo architecture actually supports the MVC pattern very well. In past projects, I've used JSPs and servlets as the controller layer, to decouple business logic and data access from the Laszlo presentation layer. Basically, the JSP/servlets need to produce XML based on GET requests invoked by the Laszlo client (see docs for the dataset tag and LzHttpDataset.)

This approach is elegant because the fundamental system remains presentation-agnostic -- i.e., you can see how you could easily leverage your same JSPs (which could just as easily be CFM, Perl, or something else) for a traditional HTML presentation layer or other integration purpose.

But in any case, to answer your original question -- It sounds like what you're looking for are controllers that broker attributes to and from the HttpSession object for use within your Laszlo app. This mechanism doesn't currently exist formally in the product, but it's pretty straightforward to create what you need using JSPs, and then access the session data through a Laszlo LzHTTPDataset.

As an example, suppose you have a web transaction where a user's favorite color has been stored in the session object with the attribute name "favorite_color" -- and you'd like to write a Laszlo app that retrieves the data, presents the user with a whiz-bang UI to change it, and then sets it back into session for later transactions.

First, you might create a getColor.jsp controller that includes code like:

<mycolor>
<%= (String)session.getAttribute( "favorite_color" ) %>
</mycolor>

This generates a simple XML structure when the JSP is invoked. (If your session attribute is a more complex object, your JSP would have to traverse it and output XML that mapped to the desired data.)

Now, to access this data from within a Laszlo application, you'd declare the following dataset somewhere at the <canvas> level:

<dataset name="colorData" src="http://localhost:8080/myApp/getColor.jsp" />

Later when a request is made to the dataset (using LzDataset.doRequest() or autorequest), the colorData dataset nodes and attributes can be accessed via the LzDatapointer API. (There are also a number of ways to instantiate Laszlo views and text objects based on the dataset response.) Note that the LPS passes the browser cookie along with the request properly so that the appropriate session is identified.

Similarly, a controller JSP can be written to put attributes into session after you're done with your UI interaction -- in it's simplest form, you might have a changeColor.jsp that is called with a query string (set using LzDataset.setQueryString()):

http://.../changeColor.jsp?newColor=burnt%20sienna

This JSP, when invoked, would set the session attribute "favorite_color" with the value of the query string parameter "newColor":

session.setAttribute( "favorite_color",
request.getParameter( "newColor" ) );

In this case, the JSP's resulting XML might simply include a success/failure flag, indicating whether there were errors in the process.

This approach allows you to architect your application flexibly, so that you can choose whether specific logic is placed in Laszlo presentation code, your controller JSP or servlet layer, or in Java classes that are called by your controllers.

Finally -- notice that this architecture works in exactly the same way if you wanted to use JSPs or servlets (or CFM or Perl or...) as controllers for database access as well.

Hope this helps -- does this answer your question at all, or am I the one rambling...?

[knuckleswanny]

Thanks jtang, I will look closer at the LzData set stuff. Let me see if I understand the really high level gist of your post. Basically what I think I read is that I can use XML as the sort of go-between. That I can use, maybe not JSP's,(I'm not a huge fan) but something else to create XML that the laszlo view can read using the session and request/response paradigm. Is that right?

[jtang]

You've got it. Hmm -- guess I really only needed 1 line to explain. Oh well... :)

In any case, definitely check out http://www.laszlosystems.com/developers/learn/documentation/tutorials/data.php for more info on interacting with data in LZX.

[k07032]

Hi all,
can any one of you post some sample source code as I'm totally new to Laszlo and spring mvc?
Thanks.