Re: Ajaxifying the ImageMap widget
Ciao Gabriele
On 24 Nov 2006, at 18:27, Gabriele Columbro wrote:
Hi devs!
I'm currently working togheter with Luca Morandini on a GIS project
based on Cocoon 2.1.9, of course using the ImageMap [1] widget that
Luca contributed nearly one year ago.
After having developed the whole application (based on Geoserver
[2] as WMS/WFS server and Weblogic 9.2 as appserver) in the plain
old full page refresh mode, we had a sudden requirement change that
forced us to switch to a more buzz-word driven ( Ajax ;-) ) approach.
All went smoothly (ajax=true is almost the only change I needed,
making bosses astonished, thx guys) until I had to make the
imagemap widget value change after am XHR ( i.e. update the src of
the input type=image that represents the map and tells geoserver
how to draw the map). I discovered, in fact, that the ImageMap
widget was never calling the
org/apache/cocoon/forms/formmodel/Form.java#addWidgetUpdate
( org.apache.cocoon.forms.formmodel.Widget)
method, that then triggers the Browser update process.
Once I patched this (of course planning to contribute it, but
waiting for a completely working version) all actions performed on
other widgets *but the map* were correctly reflected on a partial
update on the map (in case its server side state was modified), but
I'm now facing a different problem handling clicks *on* the map:
whereas a full page submit on an input type=image sends two
parameters ( /widgetId.x/ and /widgetId.y/ , i.e. the coordinates
of the mouse click) that are used to recompute map extent, the XHR
is just not sending this parameters (verified with tcpmon), so that
map status does not get modified, and map not redrawn.
I'm stuck as I don't know where to take action, wheter if it's a
dojo framework lack (I'm using the jar that is contained in cocoon
2.1.9, should I try with the latest trunk?), or it's a problem of
the dojo-cocoon js bridge.
It would be great if someone can point me to the right direction,
also because I think that this can be a good (and contributable)
improvement for the imagemap widget to support AJAX, in a web world
where ajax maps are now the standard.
Your problem lies here, I think :
src/blocks/forms/java/org/apache/cocoon/forms/resources/js/common.js
in cocoon.forms.buildQueryString line: 109 :
if (input.type == submit || input.type == image ||
input.type == button) {
// Skip buttons
continue;
}
Your image-type input is not added to the query string.
You could patch this function to output what you need.
Alternatively it is possible call cocoon.forms.CFormsForm.submit
(name, params) directly and pass the 'name' of the submitting control
and extra form parameters in 'params' (an associative array).
This has changed in 2.1.10-dev, as I re-wrote all of this stuff to
add the ability to send XHR via IframeIO if there are file-type
inputs. I threw the buildQueryString function away and use Dojo's
built-in code for assembling the form.
HTH
regards Jeremy
PS. Are you sure this will look good though ? If what you are doing
is just re-centering the map on the new coords, I'd be tempted to
write a Dojo WIdget to handle this itself, give you a smooth scroll
to the new centre (everyone is used to Google Maps etc.) rather than
replace the image using BrowserUpdate. (Just my humble opinion ;))
smime.p7s
Description: S/MIME cryptographic signature
Re: getting started with 2.2
On Nov 22, 2006, at 10:25 AM, Jeremy Quinn wrote: Hi Mark So you have the samples running now ? I still cannot .. Is it best to use Java 1.4 or 1.5 I am using 1.5. Hi Jeremy — sorry, didn't see your email 'til just now... 1) Yes, I have samples running; 2) I'm using 1.4 on this machine. cheers, —ml—
Re: Problem with JAXP and shielding (was Re: Shielded class loading between blocks)
Alexander Klimetschek wrote:
The problem also exists without my ShieldingBlockServlet, I just tested
serving jsps from a sitemap that is part of a normal cocoon webapp with
shielding done by the deployer plugin and the same exception pops up
upon requesting the jsp.
The actual bug is that the cocoon-jsp block does not work with any kind
of shielding, since it uses the jasper jsp engine provided by the webapp
and that one expects its own JAXP implementation. The jasper jsp engine
can be loaded, but during compiling of a jsp it tries to load some JAXP
class, which fails, because that loading is done by the shielding
classloader, which has another version of Xerces and xalan. (IIRC, the
latter point is the reason for shielding anyway, since many
transformation stuff done with cocoon sitemaps does not work with older
XSLT implementations provided by the webapp container - some really
annoying problem we already stepped into).
Yepp, you're right of course - so just forget my last answer.
A solution to that kind of problem is not easy. The first idea would be
to explicitly check for the classloader in the cocoon JSP component
before executing the Jasper enginge, but how do you find out if you got
a shielding classloader or not? You cannot cast, not for the
ShieldingClassLoader which will be part of the maven-war-plugin you
don't want to have a dependency to, and also not for the
WebappClassLoader, because that one is webapp container specific (and
there is no API for that in the servlet specs).
So a dirty Hack would be to do a check like
ClassLoader cl = this.getClass().getClassLoader();
// step over all shielding class loaders to find the webapp classloader
while (cl.getClass().getName().indexOf(Shielded)) {
cl = cl.getParent();
}
// set cl as context classloader
// start jsp engine
Looks kinda ugly
Definitly - now, what about adding the jasper engine to the classpath of
the webapp
by putting it in web-inf/lib?
Looking at this scenario, I have the feeling that sooner or later you
hit similar problems in other cases as well. As soon as you access
something the container provides for you, you might end up with the same
mess.
So, perhaps we have to take a step back and think, why we think that
shielded class loading is a great feature. One reason is commons logging
(which should be solved with newer versions) and the other one is the
endorsed problem with Xalan and Xerces as the most promintent candidates.
Perhaps our blocks concept helps here? If our xslt transformer would be
in its separate block using its own class loader with its own version of
Xalan, the problem would be solved as well. Everything else could run in
the webapp classloader.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: 2.2 replacement for GlobalInputModule?
Mark Lundquist wrote:
Or, trunk still has the DefaultsModule. Maybe that's what I really
want here?
Hmm, my question is: what do you really want? :) Where do you want to
define what?
Carsten
—ml—
On Nov 24, 2006, at 11:12 AM, Mark Lundquist wrote:
On Nov 21, 2006, at 5:19 PM, Mark Lundquist wrote:
I was actually hoping to add an attribute-driven form form to
GlobalInputModule, so that you could have, e.g.
some-var value=/whatever/{some-module:xxx}/foo/bar/
(typically the input module would be a PropertyInputModule)...
Yeah, and, you know... I'm still thinkin' that would be nice. How
about:
(a) Putting back the GlobalInputModule in trunk;
and,
(b) Referencing the Settings items using a different scheme, e.g.
{settings:whatever}
??? WDYT?
—ml—
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: 2.2 replacement for GlobalInputModule?
On Nov 25, 2006, at 10:15 AM, Carsten Ziegeler wrote:
Hmm, my question is: what do you really want? :) Where do you want to
define what?
Hi Carsten...
The sitemap variable syntax only works in attributes, right?
To recap from a previous message, I wanted to add an attribute-driven
form to GlobalInputModule so that you could say something like this:
map:component-configurations
map:global
something
value=context://this/that/{some-module:xxx}/foobar.xml
map:global
map:component-configurations
and I'm (a) looking for an alternative in the post-GlobalInputModule
world, or (b) failing that, lobbying for the reinstatement of
GlobalInputModule.
thx,
—ml—
Re: getting started with 2.2
Hi Mark, Thanks for the reply. I recompiled and ran the samples under 1.4 successfully !! So my problems lay in trying to use Java 1.5. Many thanks regards Jeremy PS: These were my steps : $ mvn -Dmaven.test.skip -Dallblocks - Dmaven.war.shieldingclassloader=false clean install $ cd dists/cocoon-dist-samples/ $ mvn clean package $ mvn jetty:run On 25 Nov 2006, at 17:00, Mark Lundquist wrote: On Nov 22, 2006, at 10:25 AM, Jeremy Quinn wrote: Hi Mark So you have the samples running now ? I still cannot .. Is it best to use Java 1.4 or 1.5 I am using 1.5. Hi Jeremy — sorry, didn't see your email 'til just now... 1) Yes, I have samples running; 2) I'm using 1.4 on this machine. cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
many methods in BlockCallHttpServletRequest not supported yet.
Hi, There are many methods not supported in BlockCallHttpServletRequest yet, like getLocale(). We are converting our project to use cocoon-blocks-fw-impl but many of our sitemaps use LocaleAction which calls getLocale() in request. Just like to know whether these methods will be implemented soon. Or we should just hold on the conversion. Rice
