Re: [C3] Sting template, passing argument to method
Andre,
In my opinion, if you are dealing with XML data, you should turn your eyes
into XSL[T] instead of ST.
Greetings,
Greg
2012/10/5 André Juffer andre.juf...@oulu.fi
On 10/05/2012 09:30 AM, Francesco Chicchiriccò wrote:
On 04/10/2012 08:53, André Juffer wrote:
Hello,
I am dealing with the following problem. A REST resource returns an
(DTO) object called statistics (of type Statistics) holding various
properties. With string template, each property can be inserted into
an XML file, like
A$statistics.propertyA$/A
where the corresponding method on the Statistics object is
getPropertyA().
One of the properties requires an argument of type String, where the
actual method signature is getNumberFor(String name). It returns an
int. The name is obtained from a list of names obtained from the
statistics objects as well. The idea is to iterate through the list of
names and return a number (int) for each name.
Thus, the XML code that I try to complete looks like:
socials
$statistics.names: { name |
social
name$name$/name
number$statistics.numberFor(**name)$/tribc:number
/social
}$
/socials
The Statistics object holds among other things a MapString, Integer
with the requested numbers.
The line $statistics.numberFor(name)$ is however erroneous. I cannot
pass the current value of name to the method in question.
My question is now: How to pass a argument to a given method on an
object using string template. The string template website did not give
a clear answer, so maybe it is not even possible, or maybe I just
completely overlooked it.
Any help is appreciated.
Hi André.
I am not an ST expert at all, but I really think there is no support for
generic method invocation on ST expressions: the only methods supported
seem to ne related to properties, à la JavaBean.
Yeah, that's what I thought.
For your use case, I'd change a bit the application logic by providing a
C3 REST controller that would act as a data conversion proxy between
the sitemap and the actual REST resource you are currently dealing with.
In this way you could query the external REST resource from the C3 REST
controller body and prepare the data in a format that's suitable for ST.
OK, I'll have a look at this. Alternatively, I may simply add a method to
the DTO that returns an XML representation of the DTO. With ST, one would
use then $statistics.asXml$ or something, but it appears that all and
symbols are replaced with lt; and gt; which is not what I want of course.
Thanks,
Andre
Regards.
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juf...@oulu.fi
University of Oulu, Finland | WWW:
www.biochem.oulu.fi/**Biocomputing/http://www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
Triacle Biocomputing | WWW: www.triacle-bc.com
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@cocoon.**apache.orgusers-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Forms and maps
Hello, I would like to share my opinion on C3. I think that dropping support for the most of native Cocoon components is a good step forward. As you see trends now in enterprise applications, everybody from RedHat to Oracle limits the amount of code from bare application server core engine making it smaller, lighter and faster. As to additional components or modules they are only supported if compliant with standards and mostly through separate bundles/libraries or connectors. There is 1 standard in Java world concerning Enterprise Java Apps - its Java EE. And C3 adheres to that standard through the strong RESTful Web Services support. And I think the goal is to provide very light and fast web services engine besides being robust integration platform. And in order to stay competitive it must adhere to standards. Nobody will be interested in developing non-standard components that are just equivalents of other standard-compliant frameworks/bundles. Instead of writing its own versions of additional components Cocoon should provide support for any necessary standard on the market through the use of connectors/API to components/technologies that are already used in other frameworks. That reusability guarantees further development of the whole platform. If you design your application by decoupling functionality among separate services which is the concept of SOA, its very important to have very loosely coupled components that can support any technology available on the market. Its a nonsense and very error-prone trying to provide native modules for any relevant technology. And if some technology works better than other one, why not just use it? It relates to Cocoon Forms and Wicket or JSF. Any competitive platform now should be opened to any available technology and should provide support for such one, while concentrating on its core job - in case of Cocoon I presume it to be extensive XML processing and RESTful Web Services. According to my experience with Cocoon its a very robust platform in terms of XML processing and data integration. And while we still use very old release in production - 2.0.5, it still meets our goals by providing functionality similar to today's ESB and a mix of WS-* (SOAP) and RESTful Web Services. In case of web front-ends, we don't use any non-standard compliant modules like Forms. Instead we use a bunch of open reliable external libraries like JSTL, Velocity, Dojo, jQuery or jQuery Mobile to build very satisfactory user-experience. We also make extensive use of Google Maps through Google Maps API from Javascript/jQuery. We don't need and don't want to use any non-standard Google Maps component from Cocoon. Its all about the design of your app. Greetings, Greg 17-04-2012 22:50, Alberto abros...@ogs.trieste.it napisał(a): On 04/13/2012 07:18 PM, Mika M Lehtonen wrote: Interesting, I am also integrating maps into sites produced with Cocoon 2.1x. I have no answer to you but maybe we could collaborate on this issue? OpenLayers widget would be something! Just some considerations. I like very much cocoon, its philosophy, and the way to produce application with it and especially with forms. But we must remain realistic: in the last years the pace of the develop of cocoon is slow and the next release will be something different. For example, the integration with Wicket seems to be the sign that forms will not be more developed. Due to the fact that I don't know how to develop a new widget for cocoon, I was waiting for some clue or suggest to evaluate the effort needed. Unfortunately I have not received any answer so I'm considering to invest my time in another framework (Wicket) that can solve this kind problem and has a future more outlined. Ciao Alberto cheers, mika 13.4.2012 20:03, Alberto kirjoitti: Hi, I'm using cocoon 2.1.12-dev and I'm facing how to include a map in cocoon forms. I have to do simple things from flowscript: load a kml url and receive the coordinates of an area selection. I'm considering to use OpenLayers or Google Maps. Looking sources I found already existing widget classes for GoogleMaps (org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and using it I have the following error: Non-existing component for this hint (Key='googlemap'). Moreover it seems it lacks methods to load a kml file. So, which is the best way to do it? The googlemap widget is working? I have to write a new widget following the document http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets? Any suggest is welcome Best regards Alberto - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional
Re: C3 and XSP equivalent
Thank you Francesco for your reply. That clarified my Cocoon upgrade path plan for the future. I will be looking forward to seeing C3 beta released :) I must say that you guys are doing a really great job with Cocoon. I didnt find any other lightweight XML/RESTful engine that is so flexible and easy to develop on. jBoss 7 Community Edition is also in our consideration as an OSGi-based very lightweight/modular Web Services engine and has really small footprint but it still cannot beat C3 in terms of declarative way of handling XML chain processing. We tried also Apache Camel / CXF as another possible candidate to meet our goals, but it lacks some features. C3 looks like the best one. We live in times when there is a tremendous pressure to deliver short-term results/fixes and the price of introducing a new change must be very low. In my opinion C3 fits that like anything else. Thank you and please carry on with developing that wonderful piece of software. I hope to see OSGi support soon :) Greetings, Greg 2012/4/4 Francesco Chicchiriccò ilgro...@apache.org Hi Greg, sorry for the delay: you will find my reply embedded below. Regards. On 02/04/2012 11:00, gelo1234 wrote: Hello, We've been using Cocoon framework for years and are very happy with its simplicity and RAD features. Although we use very old version of Cocoon (2.0.5), it still satisfies us. Unfortunately there are some bugs inside those old framework libs that we cannot fix as well as some memory leaks from libraries that are no longer in use. That's why we soon plan to upgrade to the newest release of Cocoon. And i have few questions related to that topic: 1. Is C3 stable enough to give it a try in a production ? Stable enough to give a try? Yes. Ready for production? No, unless you have enough skills to dive inside the source code. There are C3-based projects in production out there, but latest release is alpha [1], and development version is still beta1. 2. Is there any equivalent of XSP in C3 ? Not really. As you say below, XSP were already deprecated in C2.1. The only template mechanism available in C3 is StringTemplate [2] which is way less flexible (and error-prone) than XSP. The flexibility of XSP is very important to us in terms of introducing many new/short changes very fast to our web application. We just make a change and that's all - cocoon engine recompiles the java-related class and it is instantly available to us - no recompiling from our dev team, no deployment, no app server restart no fuss at all! It allows us for very rapid changes! That's exactly the kind of flexibility we want to have in our dev environment. And we were much worried when in next Cocoon releases the support for XSP was abandoned. As far as i know XSP became deprecated in C2.1.11 to be totally removed in C2.2.x and i suppose in C3. I didn't dig much into all the features of new Cocoon but it seems like in C2.1/2.2 the best thing to use on the controller side is Flowscript code. We were hesitating to switch from pure Java controller code to Javascript/Flowscript code because in my opinion the continuation mechanism is error-prone, yet the developer must take care of many intricacies around session/continuation expire times and so on. But the main reason for us not to go for it was the language - Javascript - NOT Java. Although if i get it right, you can just instantiate any Java object and get access to any Java library available around from Javascript, it is not as much flexible as java was in XSP. Though it still doesn't require any recompiling!/redeployment phase from the dev team as i assume. In C3 you can have Java controllers called and that is Good, but it does require recompiling the Java class and redeploy it on the server (and restart app server?). So it will be much much SLOWER than just dynamic-recompiling by cocoon engine without any server restart. So i wonder if there is any mechanism on the controller side available in C3 that enabled us to still use Java but doesn't require from us recompiling java code/making redeployment/restarting the application server ? Sure: you can empower cocoon-maven-plugin [3] for this, or even setup something external like JRebel. 3. Is Flowscript using some separate javascript engine like V8 ? Is it run inside JVM as a dynamic language feature ? Whats is a preferred method to be used as a logic controller in C3 - Flowscript or Java ? There is no support at all for Flowscript / continuations in C3. 4. We don't want to go yet with C3 alpha-3 because it still uses old Xerces and XML-API libs. We found out there are some issues with those old libs under Tomcat 7 while working with bloated XML namespaces or handling some SAX errors. They had led to some memory leaks in our environment. I spotted on the changelog that you have just updated C3 beta to the newest Xerces/XML-APIs. Thank you very much for this. I really appreciate
C3 and XSP equivalent
Hello, We've been using Cocoon framework for years and are very happy with its simplicity and RAD features. Although we use very old version of Cocoon (2.0.5), it still satisfies us. Unfortunately there are some bugs inside those old framework libs that we cannot fix as well as some memory leaks from libraries that are no longer in use. That's why we soon plan to upgrade to the newest release of Cocoon. And i have few questions related to that topic: 1. Is C3 stable enough to give it a try in a production ? 2. Is there any equivalent of XSP in C3 ? The flexibility of XSP is very important to us in terms of introducing many new/short changes very fast to our web application. We just make a change and that's all - cocoon engine recompiles the java-related class and it is instantly available to us - no recompiling from our dev team, no deployment, no app server restart no fuss at all! It allows us for very rapid changes! That's exactly the kind of flexibility we want to have in our dev environment. And we were much worried when in next Cocoon releases the support for XSP was abandoned. As far as i know XSP became deprecated in C2.1.11 to be totally removed in C2.2.x and i suppose in C3. I didn't dig much into all the features of new Cocoon but it seems like in C2.1/2.2 the best thing to use on the controller side is Flowscript code. We were hesitating to switch from pure Java controller code to Javascript/Flowscript code because in my opinion the continuation mechanism is error-prone, yet the developer must take care of many intricacies around session/continuation expire times and so on. But the main reason for us not to go for it was the language - Javascript - NOT Java. Although if i get it right, you can just instantiate any Java object and get access to any Java library available around from Javascript, it is not as much flexible as java was in XSP. Though it still doesn't require any recompiling!/redeployment phase from the dev team as i assume. In C3 you can have Java controllers called and that is Good, but it does require recompiling the Java class and redeploy it on the server (and restart app server?). So it will be much much SLOWER than just dynamic-recompiling by cocoon engine without any server restart. So i wonder if there is any mechanism on the controller side available in C3 that enabled us to still use Java but doesn't require from us recompiling java code/making redeployment/restarting the application server ? 3. Is Flowscript using some separate javascript engine like V8 ? Is it run inside JVM as a dynamic language feature ? Whats is a preferred method to be used as a logic controller in C3 - Flowscript or Java ? 4. We don't want to go yet with C3 alpha-3 because it still uses old Xerces and XML-API libs. We found out there are some issues with those old libs under Tomcat 7 while working with bloated XML namespaces or handling some SAX errors. They had led to some memory leaks in our environment. I spotted on the changelog that you have just updated C3 beta to the newest Xerces/XML-APIs. Thank you very much for this. I really appreciate that important change. Can we have some light on when the beta is released ? Greetings, Greg
