Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: 
 <1E0CC447E59C974CA5C7160D2A2854EC02FECBEB@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: <dev@cocoon.apache.org>
Date: Fri, 2 Jan 2004 17:08:00 -0600
Subject: Accessing flow context attributes
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-SEF-723560E2-3392-41F8-A983-A3F5486E94A: 1
content-class: urn:content-classes:message
Thread-Topic: Accessing flow context attributes
Thread-Index: AcPRhUTZP4HDjv//RaGH76dbUts+4w==
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

As per my previous post I'm having problems accessing a request
parameter if it was previously set via the query string.  Assuming that
the query string always overrides the request parameters I figured a
good alternative would be to move the management of this particular
variable out of the front end requesting frame and into the back end
flow script; in this particular case it helps determine what screen to
show and makes perfect sense in the flow script.  So I coded a flow
script with statements like:

    cocoon.sendPage( "run/_page/" + collection, {
"layout_type_preference" : "list" } );

However, this particular parameter is actually needed in a generator.
I'll end up setting a request attribute and managing things that way.
However, while figuring this all out I took an interesting tour through
the guts of Cocoon and discovered what looks like the same code cut and
pasted about a dozen times through out the Cocoon source.  In
particular, everyone uses almost the same code (right down to the "Hack"
comment) to set the parameters in their generators.  The following
sample is from  JXTemplateGenerator:

    private void fillContext(Object contextObject, Map map) {
        if (contextObject =3D=3D null) return;
        // Hack: I use jxpath to populate the context object's
properties
        // in the jexl context
        final JXPathBeanInfo bi =3D
            JXPathIntrospector.getBeanInfo(contextObject.getClass());
        if (bi.isDynamic()) {
            Class cl =3D bi.getDynamicPropertyHandlerClass();
            try {
                DynamicPropertyHandler h =3D (DynamicPropertyHandler)
cl.newInstance();
                String[] result =3D h.getPropertyNames(contextObject);
                for (int i =3D 0; i < result.length; i++) {
                    try {
                        map.put(result[i], h.getProperty(contextObject,
result[i]));
                    } catch (Exception exc) {
                        exc.printStackTrace();
                    }
                }
            } catch (Exception ignored) {
                ignored.printStackTrace();
            }
        } else {
            PropertyDescriptor[] props =3D  bi.getPropertyDescriptors();
            for (int i =3D 0; i < props.length; i++) {
                try {
                    Method read =3D props[i].getReadMethod();
                    if (read !=3D null) {
                        map.put(props[i].getName(),
                                read.invoke(contextObject, null));
                    }
                } catch (Exception ignored) {
                    ignored.printStackTrace();
                }
            }
        }
    }

It seems to me that this really needs to be refactored into some helper
class, though I'm not sure where?

Peter Hunsberger