How to achieve proper layer separation in xpage (that is, talking to Java objects instead of domino views and domino documents)

I am trying to implement appropriate layer separation in my xpage project Ideally, I try to reach the point where XML in xpage does not contain ssjs and only uses el to access Java objects

So far, I have studied how to load all my data from domino database into Java beans (where 1 document = 1 object, more or less). I am reading the view content into Java maps or lists, and I have managed to display the contents of these collections in duplicate controls

What I'm not sure is how to display the contents of the "form" of a single document without referencing domino documents In particular, I am not sure how to deal with the "new document" case I think I created an empty object and set it as the data source of xpage

I know I have to use ObjectDataSource, but I'm not sure where to store it I read an article by Stephan wissel, saying that they should not be placed in managed beans, so where can I put it? In a scope variable like viewscope?

Now I write an 'applicationbean', which is a session - wide managed bean, and I store all the objects

What are best practices? There seem to be many different ways to achieve this goal I'm currently exploring Christian g ü Demann's xpages toolkit, which sounds very promising I know that Samir pipalia, John daalsgard and frank van der Linden have developed their own framework

What should I do? Any traps?

Solution

This is really a big topic As Paul mentioned, Tim's document model class is a good example of how to do this clearly. Tim introduced it in detail in the subsequent episodes of the notesin9 series The model objects of my own framework are very similar, but I also added collection managers to deal with the dirty business of accessing views For better or worse, almost every xpage developer solves this problem in a unique way

There are many ways to implement this method. Under normal circumstances, some differences are not very important (for example, whether to preload all data in the document or delay extraction when constructing model objects, and only go to the back end when needed), but there must be several primary problems to be solved

Model access

As you mentioned in the question, one of the major issues is how you actually access model objects from xpage - how to extract objects from the database or recreate objects The model objects of my framework use the attributes of "manager" objects. These objects are application wide beans that allow you to get named collections (mapped to views), Unid model objects, or get new model objects through the keyword "new" Usually, these models (serializable) are then stored in the view range of the page through < XP: DataContext / >, < Xe: objectdata / > or the framework's own < FF: modelobjectdata/ replace. I find it wise to avoid using managed beans to represent a single object (such as "currentwhatever" and then populate it with data on each page), because in the best case, it will mess up your faces config or encounter session problems The worst (I rarely use it if you put it in conversation scope) How you implement "new" and "get" model objects largely depends on the strategy you take to write the model first, but most of them come down to having two constructors: one using Unid (at least) to point to an existing file and one creating a new file If you go to "use getters and setters to explicitly write in objects" routing, the latter will also initialize all fields with default values instead of reading them from the document Internally, you should have a field to store the Unid of the document, which indicates whether it is new – then, your save method can check whether this field is empty and create a new document if necessary (and then store the Unid of the new document in this field) Look, it sounds like you've read your model collection into the lists, which is good However, one of the disadvantages is scalability: if the number of collections is small (less than 100), you may not encounter any loading speed problems, but then when the code is read in, the initial page loading speed will slow down and the whole view will advance You can use effective view reading to alleviate this, but there is a limitation Built in views are usually fast because they only load data as needed (they cheat like hell, but that's another problem)

This is a noble goal for yourself, but it is done to cover all cases. It is no small feat: you finally encounter the problems of FT search, column help, efficient data preloading (you don't want to reopen the view object only), read in one entry at a time, but you don't want to read the whole content), and use it in viewpanel and others (special interface is required), extension / collapse categories, etc This is large sub topic on its own

Secret script

You may also encounter other areas that are more difficult than you initially thought, such as "correct" rich text processing and file attachments In particular, attachments need direct conflict with the XSP framework to run normally using custom model objects and standard upload / download controls

Case sensitivity in field names is another potentially troublesome area If you are writing getters and setters for all fields, this is a meaningless problem, but if you want to use a "thin wrapper" path (I prefer), it is important to encode any intermediate cache / lookup in one way Handle the fact that "foo" and "foo" (basically) have the same project name as notes, but they are different in Java The method I take is to create an extensible use of treemaps: if string CASE_ INSENSITIVE_ Order is passed as a parameter to the constructor, which handles strings as keys, usually case insensitive

Making your model object work with all standard controls may or may not be a priority - I find it very valuable, so I've done a lot of work to implement my framework, but if you want to do some basic string and number models, you don't have to worry

So... Yes, it's a big topic! Based on your confidence in Java and xpage underlying, I suggest either choosing a fairly simple "bean with getter and setter" route for your object, or looking at the implementation details of one of the existing frameworks (my own) or those you mentioned) Unfortunately, as the code becomes more and more complex, there are many small problems, many of which are not obvious