cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <gree...@hotmail.com>
Subject Re: Persistent object with cocoon
Date Fri, 20 Oct 2000 13:41:47 GMT
"Konstantin Piroumian" <KPiroumian@flagship.ru> wrote:
>I have seen a similar question before, but did not find the answer to it.

Okay, I'll add this to the FAQ.

>
>Is there a possibility to create some objects and keep them in memory,
>f.e.: a Properties object with some application settings.
>And I want to be able to refer this object from any page.

To take your last point first - To refer to something on any page the only 
way to do it is use a logicsheet that inserts the declaration for every 
page. XSP does not yet support inheritance, which might be a better way.

For just application-wide properties you can use cocoon.properties or (in 
Servlet 2.2 or greater API engines only, i.e. not JServ) web.xml. For more 
general app-wide objects you can use "factory" classes and static variables 
(e.g. inserted into the XSP with logicsheets), and for user-specific objects 
you should use sesssions (e.g. with the session taglib).

OK, each in turn:

cocoon.properties: Unfortunately I don't think this can easily be used at 
the moment because the Configurations object is not accessible to XSP pages 
(AFAIK). Of course you can still re-read the file yourself but that is a 
pain. I think I will enable direct access if there are no objections.

How you _would_ do it ideally is override the init method like this:

<xsp:page ...>
  <!-- note this is OUTSIDE page root element -->
  <xsp:logic>
    static String myprop;

    public void init (Configurations conf) {
      myprop = (String) conf.get ("myapp.myprop");
    }
  </xsp:logic>
</xsp:page>

and add myapp.myprop=whatever to cocoon.properties.

web.xml: This is easy. Just call 
servletContext.getInitParameter("myapp.myprop") and add a suitable parameter 
to web.xml (just like for Cocoon).

"Factory" classes and static variables: (Note to myself - this is probably 
how turbine pool init should be done, instead of the current hacky init) In 
fact in XSP pages there is little difference between static and instance 
variables, because there is always only one instance of an XSPPage object 
per page, but using the modifier "static" emphasises that these are meant to 
be app-wide variables.

Example - put this in every page:

<xsp:page ...>
  <xsp:logic>
    static MyClass myObject = MyClass.getMyObject ();
  </xsp:logic>
</xsp:page>

and declare this "factory" class in its own .java file:

public class MyClass {

  private static MyClass myObject;

  // synchronized to make sure it isn't created twice
  public synchronized static MyClass getMyObject () {
    // Only create it if it hasn't already been created
    if (myObject == null) myObject = new MyClass ();
    return myObject;
  }
}

Sessions:

There's already an example of that, posted recently in the mailing list - 
I'll refer to that in the docs.



_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


Mime
View raw message