Re: How to build cocoon trunk?
Daniel Fagerstrom wrote: If you are brave enough, the best bet is by starting by taking a copy of the cocoon-webapp, rename it to something appropriate. The you update the pom to a new artifactId and to depend on the blocks that you need. You also need to copy the component (and other) configuration files _manually_ from the blocks to WEB-INF in your webapp, they are located in the WEB-INF directory of the blocks. This was done by the ant task before, but no one have written any Maven replacement yet. After this it might work ;) /Daniel Thanks a lot for your help Daniel. Vil. -- http://www.vilyaharvey.com
How to build cocoon trunk?
Hi there, After spending some time developing on Cocoon 2.1.5.1, I thought it was time to try and get up to date. I've checked out the Cocoon trunk from SVN and tried to follow the instructions in the README.m10n.txt file, but seem to keep getting problems. The first problem was that the cocoon-deployer module (in the cocoon-block-deployer subdirectory) wouldn't build. I found another thread related to that which indicated (if I understood correctly) that cocoon-deployer was not needed; I've commented it out for now. Now I'm gettting a lot of warnings about Maven being unable to get resources from various directories. I'm not very familiar with Maven yet - are these things I can ignore, or will they come back to bite me later if I do? Finally, once I have got it all downloaded and building correctly, what is the intended way of developing applications for it? I read a passing comment somewhere that user code would be written as a block and would just declare dependencies on the blocks it needs. Is that the case? If so, where can I find information about writing blocks? If not, how *should* I be writing applications for Cocoon 2.2? Any help would be very much appreciated! Vil. -- http://www.vilyaharvey.com
Re: Location of cforms stylesheets
Antonio Gallardo wrote: On Jue, 26 de Mayo de 2005, 5:21, Reinhard Poetz dijo: sorry, I don't understand this. Do you mean that some people complelty rewrite the stylesheets? Yep. Maybe not a full rewrite, but changes some things to meet some criteria. Best Regards, Antonio Gallardo FWIW that's what we've done for our app (made changes, not a full rewrite). Vil.
Re: [cForms] Errors coming from service layer
Reinhard Poetz wrote:
Thank you!
This means that the service layer is aware of which widgets exist? I'm
not sure if I (and especially my customer) likes this bi-directional
dependency ...
I agree it's a bad idea for the service layer to know about the widgets.
In our case there's a fairly simple correspondence between error types
and widgets, so we're able to infer it all in the UI layer. For more
complicated cases I could imagine using some kind of mapping, along the
same sort of lines as the form bindings. I haven't tried that out, so I
don't know how well it would work in practice.
BTW, the code to set a validation error on a widget looks like:
var myWidget = form.lookupWidget("...");
var myError = new
Packages.org.apache.cocoon.forms.validation.ValidationError(myErrorMessage);
myWidget.setValidationError(myError);
(hope that doesn't get word-wrapped...)
Vil.
Re: [cForms] Errors coming from service layer
Sylvain Wallez wrote: Reinhard Poetz wrote: Thank you! This means that the service layer is aware of which widgets exist? I'm not sure if I (and especially my customer) likes this bi-directional dependency... Nono! Your validation code has to catch the exception and translate it into a validation error. This means you can have "regular" validation errors (i.e. the backend could be reached but detected invalid data) and communication-level errors, e.g. "could not validate data, try again later". Exactly! Although in our case, the exception gets caught and translated into multiple validation errors, rather than just a single one. Vil.
Re: [cForms] Errors coming from service layer
Reinhard Pötz wrote: Imagine following scenario: You have a service layer that is exposed as web services. cForms already does as much validation as possible but some complex checks can only be performed by the backend. If I call a webservice (via Axis client) this webservice can return errors (how this is done hasn't been defined yet). Are there any best practices or experiences how to map errors coming from the service or domain layer to cForms widgets? (The error has to appear at widget level.) In your flowscript, you can create your own ValidationError object and explicitly set that on the apppropriate widget. What we did was to define our own type of exception which included information about all validation errors that were found, then wrote a simple(-ish) flowscript function which handled looking up the relevant widgets, creating the error objects and setting them into the widgets. Hope that helps! Vil.
Re: CForms in whiteboard with macros and macro repositories
Tim Larson wrote: As discussed previously, I made a copy of cforms in the whiteboard and added macro and macro repository support to the form model, binding, and template code. The code works, but there are still issues to resolve, such as svn propset's, code reorganizations, design issues, etc. I just had a narrow window of time to work on this commit today, so I thought it best to commit now while I had the chance, so others can see and work on the code, because I do not know when I will get my next chance to work on it myself. Tim, This looks really useful. I'd like to find out more & see how I can help. I've been having a look at the code in svn; is there a Wiki page on it as well, or some other place I should look for more info? Cheers, Vil ([EMAIL PROTECTED])
Re: [RT] A Groovy Kind of Sitemap
You raise a few good points, but I don't agree with all of them. You're right that XML is a given for working with Cocoon. That's not a bad thing. But people already need to know a lot more than just XML in order to understand a sitemap. There seems to be a cutoff point in the development of a cocoon site. Up to the cutoff, the pipelines stay fairly straightforward: generator, a few transforms, and a serializer; after the cutoff it becomes necessary to start adding more complex behaviour: actions, nested matchers, etc. I suspect these latter sorts of pipeline could be expressed much more clearly using a scripting language. You mention people generally have a background which includes JavaScript because it's hard to avoid learning it. If that's the case, perhaps those people wouldn't be so fazed by seeing a scripting language in the sitemap. Really it's about using the most suitable representation for the task at hand. A scripting language feels like overkill for simple pipelines, but the XML syntax is very awkward for more complicated ones. The appropriate choice comes down to how soon you feel that cutoff occurs, for the kind of sites you develop. Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Re: [RT] A Groovy Kind of Sitemap
Ugo Cei wrote: Il giorno 28/lug/04, alle 09:56, Vilya Harvey ha scritto: Interesting idea. Just out of curiosity, why Groovy and not JavaScript? I wrote it in my RT, because it's trendy ;-) Fair enough. :-) Do you intend to use Groovy in other places throughout Butterfly, or just for the sitemap? It would be nice to be able to use it for flow control, form validators/event handlers, etc. Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Re: [RT] A Groovy Kind of Sitemap
Interesting idea. Just out of curiosity, why Groovy and not JavaScript? Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Re: ClassCastException in binding framework.
Joerg Heinicke wrote: On 07.07.2004 18:01, Vilya Harvey wrote: With the Cocoon 2.1.5 release, the binding framework throws a ClassCastException if you use anything other than an in the part of a repeater binding. Is this intentional behaviour, or a bug? It's a known feature ;-) http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107906438632484&w=4 Thanks for the pointer Joerg, that does explain things a bit. It might work for you the same way as I did it here: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/samples/forms/form2_bind_xml.xml?annotate=1.4#71. I was trying to do something slightly different from that when I came across this problem: I wanted an identifier that I could use to distinguish between different rows in the form, but I only needed it in the form and not in the XML (i.e. direction="load" rather than direction="save"). I was trying to use inside the element to generate them. The workaround I found, in this case, was to get rid of the identity element altogether and move the javascript into an instead. Thanks for the reponse, Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
ClassCastException in binding framework.
Hi,
With the Cocoon 2.1.5 release, the binding framework throws a
ClassCastException if you use anything other than an in the
part of a repeater binding. Is this intentional behaviour, or
a bug?
The offending code comes from RepeaterJXPathBinding.java:
--
/**
* Get the identity of the given row. That's infact a list of all the
* values of the fields in the form model that constitute the identity.
* @param thisRow
* @return List the identity of the row
*/
private List getIdentity(Repeater.RepeaterRow row) {
List identity = new ArrayList();
JXPathBindingBase[] childBindings =
this.identityBinding.getChildBindings();
if (childBindings != null) {
int size = childBindings.length;
for (int i = 0; i < size; i++) {
String fieldId =
((ValueJXPathBinding)childBindings[i]).getFieldId();
Widget widget = row.getChild(fieldId);
Object value = widget.getValue();
identity.add(value);
}
}
return identity;
}
--
The first line inside the for statement, which retrieves a field ID, is
where the exception occurs. If you're using an binding to
generate IDs dynamically, for example, the value in the childBindings array
will be an instance of JavaScriptJXPathBinding - which cannot be cast to
ValueJXPathBinding.
I'm guessing that the correct thing to do would be to use only methods from
the JXPathBindingBase class to retrieve the identity values, but I can't see
how. I'm probably overlooking something, as I'm not very familiar with the
internals of the binding framework (yet!).
Can anyone shed any more light on this?
Cheers,
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
Re: [cforms] separating API and implementation classes
Sylvain Wallez wrote: I'd like to organize the package layout of CForm classes in order to cleanly separate API classes from implementations classes. The changes you propose all sound pretty sensible. Anything that makes it easier to extend CForms gets my vote! A nesting is currently required for convertors, since they are attached to a particular datatype. To remove this need, we may use a naming convention, prefixing the convertor and format name by the corresponding datatype component name, i.e. "long-formatting", "date-formatting", etc. Not so sure about this. Wouldn't it be better to have a datatype attribute on the convertor? Something like for example? Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Re: Custom widgets in CForms
Scott Yeadon wrote: Hello, Has anyone tried to create custom widgets within the Forms framework? Beyond the business logic of their validation rules, etc, I cannot find the code which actually creates the widgets visible user interface? Anyone got a how-to on any of this? This recently created page on the cocoon wiki may help: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsCreatingWidgets Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Re: Looking for a HowTo on adding widgets to CForms.
Thanks for that. I've been filling out the page on creating widgets as I've discovered things. Hopefully it'll help other people trying to do the same thing. I'd appreciate someone casting an experienced eye over it though, to make sure I'm not doing anything stupid. Cheers, Vil. Andreas Hochsteger wrote: Hi Vilya, I'm sorry that I can't point you to an existing HOWTO. I had the same problem some time ago when I wanted to write a new data type for CForms. Perhaps it's time to collect this information on the wiki. I've created two pages which can be filled by those who know something about these things or are forced to learn it (hint!): http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsCreatingWidgets http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsCreatingDataTypes Bye, Andreas Vilya Harvey wrote: Hi all, Lately I've been trying to add my own widget to CForms. The CForms code is fairly clear, but there seems to be a lot of places where things need to be changed/added. Is there a HowTo document anywhere which describes the necessary steps? For those that are interested, the widget I'm trying to add is an extension of the standard repeater which has built-in support for pagination. I'm fairly new to Cocoon in general, so if there's a better way to get the same result I'd love to hear it! I can imagine adding support for other widgets in future though (tree widget, anyone?), so it would definitely be helpful to have a Widget HowTo. Cheers, Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Looking for a HowTo on adding widgets to CForms.
Hi all, Lately I've been trying to add my own widget to CForms. The CForms code is fairly clear, but there seems to be a lot of places where things need to be changed/added. Is there a HowTo document anywhere which describes the necessary steps? For those that are interested, the widget I'm trying to add is an extension of the standard repeater which has built-in support for pagination. I'm fairly new to Cocoon in general, so if there's a better way to get the same result I'd love to hear it! I can imagine adding support for other widgets in future though (tree widget, anyone?), so it would definitely be helpful to have a Widget HowTo. Cheers, Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
