Gianugo Rabellino wrote:
I just committed a new WebDAV block on CVS (my very first block, so
please bear with me if I did any mistake). In its current incarnation
it's a WebDAV Source which is Traversable and Modifiable, we are using
it already in some of our projects and seems to work fine
Bertrand Delacretaz wrote:
I agree very much with Nicola, basically only one implementation of
something in the main part of the CVS tree, variants live in the
scratchpad until voted to be integrated or discarded.
I agree as well :)
In the same spirit, it might be good to ask for a vote (or
Stephan Michels wrote:
My problem with the current flow implementation is that is does not
make my life easier. In my webapp I have a lot transactional stuff,
trys/catchs and lookup stuff. So writing these things in Java is
natural for me.
In the flow discussions there have been a lot of
Stephan Michels wrote:
But, if history repeats, it will take a few decades to understand that
FSM for the web are to be considered harmful. So I don't expect
everybody to buy it right now. I'm patient :-)
Okay, maybe I'm wrong, but maybe not.
But if I understand you correct, you try to prevent
Did you miss Sylvains (and my) answer to your earlier question about the
TreeProcessor? http://marc.theaimsgroup.com/?t=10664158681r=1w=2
AFAIK Sylvain has written nearly all of (or maybe all of) the
TreeProcessor, Ovidiu created flowscripts together with Christopher.
/Daniel
Berin
[EMAIL PROTECTED] wrote:
Hi to all,
first of all sorry for my bad English and for not so much clarity in post :-)
I'm currently doing a project using Cocoon 2.1.2 .
I'm trying to find an automated way to reuse components in a pipelne, like
WebServiceProxyGenerator, to implement this flow:
-
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
[EMAIL PROTECTED] wrote:
Hi to all,
first of all sorry for my bad English and for not so much clarity in
post :-)
I'm currently doing a project using Cocoon 2.1.2 .
I'm trying to find an automated way to reuse components in a pipelne,
like
Guido Casper wrote:
Christopher Oliver wrote:
Why not have processPipelineTo take a javax.xml.transform.Result
instead of an OutputStream?
Yes, that might be a good solution (although back incompatible IIUC).
Buffering in a byte array might also work. I'm just (overly?) worried
about the
Reinhard Poetz wrote:
Hello,
Cocoon has voted in a new committer. Please set up the new account.
Full name:Daniel Fagerstrom
Preferred userid: danielf
Thank you Reinhard, and thanks all of you for your confidence in me and
for all your kind comments during the vote. I feel deeply
Christian Haul wrote:
Marc Portier wrote:
Hunsberger, Peter wrote:
All right, I'll bite, how would you go about doing that? That was my
first thought but I couldn't find a way to do that...
hm. I thought there was an inputmodule for this.
Now there is. I just checked in a FlowAttributeModule and
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator and
the PartSource.
* XModuleSource - Read and write XML data (DOM and XMLizable) from input
and
Reinhard Poetz wrote:
From: Daniel Fagerstrom
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by
...
* XModuleSource - Read and write XML data (DOM and XMLizable)
...
If you have time some examples would be great!
Especially
Joerg Heinicke wrote:
On 08.01.2004 18:00, Daniel Fagerstrom wrote:
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator
and the PartSource.
* XModuleSource
Joerg Heinicke wrote:
On 08.01.2004 18:00, Daniel Fagerstrom wrote:
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator
and the PartSource.
* XModuleSource
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
...
[Read|Write]SessionTransformers
---
...
I forgot to mention the problem with output modules that I described
Vadim Gritsenko wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and
FragmentExtractorTransformer
Hm. Correction
Christian Haul wrote:
Daniel Fagerstrom wrote:
snip what=cool stuff/
Open Issue
--
A peculiarity in the RequestAttributeOutputModule and
SessionAttributeOutputModule is that they as default prefix all
attribute names with
org.apache.cocoon.components.modules.output.OutputModule, why
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Another question: do we want to cleanup flow/woody a bit and remove
deprecated files/classes, such as non-FOM flow and woody.js?
+1
Better yet, let's start VOTE thread. Please cast your vote on following:
1) Remove
Leszek Gawron wrote:
The whole module idea is really great but (please correct me if I'm wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return ObjectModelHelper.getRequest(objectModel);
getRequest returns
Upayavira wrote:
Leszek Gawron wrote:
The whole module idea is really great but (please correct me if I'm
wrong):
map:generate type=file src=module:request:inputStream/
The o.a.c.components.modules.input.RequestModule provides this:
return ObjectModelHelper.getRequest(objectModel);
Leszek Gawron wrote:
curl -T test.xml
http://localhost:/samples/scratchpad/module-source/test3
this is a tool I was looking for :) up till now I was using pure telnet.
Yes, it is very usefull, we use it a lot :)
I don't use XSP. Using flowscript I would write a pipeline consisting of
a
Yatin Shah wrote:
How does one access the flowscript objects from a site map?
[...]
You can use the FlowAttributeModule in the scratchpad block.
/Daniel
Nicola Ken Barozzi wrote:
Daniel Fagerstrom wrote:
...
I completely agree with that getInputStream should be added to the
request interface.
Pretty please :-)
I gave some arguments for doing it in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104213670731308w=2,
there where also
I'm -0 for the idea of a Woody scratchpad. We are also using Woody in
development projects so I understand your concerns. But I believe that
creating a Woody scratchpad area right now would make more harm than good.
I think there are two main reasons for puting something in a scratcharea:
*
Tim Larson wrote:
On Thu, Feb 12, 2004 at 07:24:03PM +0100, Daniel Fagerstrom wrote:
I'm -0 for the idea of a Woody scratchpad. We are also using Woody in
development projects so I understand your concerns. But I believe that
creating a Woody scratchpad area right now would make more harm
Somewhat OT, I think that the current use of the id attribute in the
Woody widget definition (WD) file is unfortunate. Id attributes are
supposed to be unique in an XML document according to the standard, and
as id in WD files rather describe a relative position in a widget
hierarchy, there
Guido Casper wrote:
Daniel Fagerstrom wrote:
Bruno Dumon wrote:
I don't think so. An attribute called id has no special meaning in
XML.
See http://www.w3.org/TR/2004/REC-xml-20040204/#id :
Validity constraint: ID
Values of type ID MUST match the Name production. A name MUST NOT
appear more
Carsten Ziegeler wrote:
In the scratchpad is the portlet environment which allows Cocoon
to act as a JSR-168 producer.
The portal block contains the JSR-168 consumer implementation.
I propose to move the producer part from the scratchpad into
the block combining both and maintaining everything
Upayavira wrote:
Reinhard Poetz wrote:
From: Alan
Working on it. As noted, I have JAXP implemented and SAX interface
to XUpdate. I have APIs. I am going to start working on services
next.
A Cocoon generator that takes a Momento data source and an XSLT
transform would be a start.
Reinhard Poetz wrote:
...
It would be very cool if we could provide something that helps with flow
applications. I like the combination of OR-Mapping/CForms/Flow but this
is for many beginners overkill. They shouldn't be forced to write Java
code e.g. in order to implement a simple register form.
The current discussion about Cocoon database connection and some
frustration about the complexity in connecting Woody based webapps to
XML makes me think that it is time to take a new discussion about the
principles for Cocoon input handling (see [1] for an earlier discussion).
But before
Reinhard Poetz wrote:
After using Cocoon for years I still think we are not very clear in
telling our users what is the right tool for their needs. Of course this
depends on their use cases and their skills.
I see three different Cocoon databases szenarios:
1. Use Cocoon in enterprise szenarios
Brian McCallister wrote:
it seems to me the embedded Xindice option should work pretty
painlessly for most simple persistence needs. If it is hard to use,
the better option may be to look at how to make it easier to use. If
an XML - rdmbs automapper and schema generator is needed it seems a
Stefano Mazzocchi wrote:
After a long silence, Daniel fights back :-)
:)
On Feb 25, 2004, at 10:49, Daniel Fagerstrom wrote:
[snip very good summary]
To sumarize: I think that we could make Cocoon considerably easier to
use for (web)apps and increase reuse of components by using the
XML
Reinhard Poetz wrote:
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Reinhard Poetz wrote:
After using Cocoon for years I still think we are not very clear in
telling our users what is the right tool for their needs. Of course
this depends on their use cases and their skills.
I see three
Bertrand Delacretaz wrote:
Le Mercredi, 25 fév 2004, à 16:49 Europe/Zurich, Daniel Fagerstrom a
écrit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure i.e. DOM. This leads to flowscript components
that reads some
Mercredi, 25 fév 2004, à 16:49 Europe/Zurich, Daniel Fagerstrom a
écrit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure i.e. DOM. This leads to flowscript components
that reads some input format to DOM and from DOM to some
Steven Noels wrote:
On 25 Feb 2004, at 22:53, Daniel Fagerstrom wrote:
CForms should use typed DOM as form model
---
I also believe that making CForms use typed XML as data storage is
important. This obviously require some changes, among other things
Sorry for dissapearing after having started this discussion.
Guido Casper wrote:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-23 15:21]:
snip/
XSLT
A MomentoSource would also give a good way to use Momento together with
XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of
sources somewhat, let me explain:
The Source interface provides
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 15:49]:
Why Cocoon rocks for publishing
---
Cocoon is based on three great ideas: XML-adaptors, XML-pipelines and
the sitemap. Here we will discuss the first two.
If you have N different input formats
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 21:53]:
snip/
XML centric view on input
-
The most important part is not a code change but rather a design
principle: Input handling is controlled from flowscripts, the flowscript
typically adapt various input
Sylvain Wallez wrote:
snip/
So let's finally vote on this.
- do you want to add an importance=high|low|medium attribute on
action in changes.xml?
+1
- do you want each block to have it's own status.xml file?
+1
/Daniel
Reinhard Pötz wrote:
As you may saw I've reverted the removal of Woody. IMO just for now and
it should be removed ASAP. So let's vote on this:
variant A: remove Woody after 2.1.5 release
+1
variant B: remove Woody after 2.1.6 release
+0
variant C: leave Woody where it is and mark it as won't
Reinhard Pötz wrote:
Stefano Mazzocchi wrote:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+1
/Daniel
Marc Portier wrote:
snip/
For the interested reader, some more info:
[1 - on the reported error]
The error 'factory is not set' from jxpath indicates that no
node-factory (jxpath terminology) is available (to the jxpath context)
to create new 'nodes' in the backend (i.e. a bigger array in the
Stefano Mazzocchi wrote:
snip/
I believe that inputmodules/outputmodules do already pose a significant
complexity to the clean separation.
Care to explain and examplify why you believe so?
I would certainly agree about that some of the modules; the meta
modules, the database modules and the
Hunsberger, Peter wrote:
Daniel Fagerstrom [EMAIL PROTECTED] writes:
snip/
I believe OTH that some of the simpler input modules,
especially the
request module, the request attribute module and the flow attribute
module, makes it possible to have a *cleaner* SOC, than it is
possible
Christopher Oliver wrote:
Reinhard Poetz wrote:
snip
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
Nicola Ken Barozzi wrote:
Since we are working a lot with branches, and there will be even more
moving stuff around when the blocks will hit the street, I propose
that we move Cocoon to use SVN. It works very well and we will be
pushed to use it in any case in the near future.
+1
+1
/Daniel
The licensing problems can be solved by writing the validation
transformer in terms of the JARV api,
http://iso-relax.sourceforge.net/JARV/. Then JARV have a run time
discovery mechanism for finding the actual implementation of the schema
language,
I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter
between a form object and a simple XML format that can be used without
needing to wriite a binding definition.
In the applications where we have used cforms we mostly have connected
the form objects to XML through the binding
Andreas Hochsteger wrote:
Hi Daniel,
this sounds really interesting!
Would this functionality allow you to bind XML content to a textarea
input element too?
What I mean is, that this way you could populate certain parts of an XML
document directly with the XHTML-Output of the HTMLArea control
Bruno Dumon wrote:
On Tue, 2004-06-08 at 18:11, Daniel Fagerstrom wrote:
I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter
between a form object and a simple XML format that can be used without
needing to wriite a binding definition.
snip/
WDYT?
Very useful addition. I've been
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter
between a form object and a simple XML format that can be used without
needing to wriite a binding definition.
Thank you very much! I think this is a very valuable addition
Bruno Dumon wrote:
On Wed, 2004-06-09 at 10:36, Daniel Fagerstrom wrote:
snip/
In such case, that is not what I want to achieve, I think that the
XML format should be locale independent (at least as default),
I think so too
how do
one implement that?
simply use Locale.US?
Seem like a better
days to call a Web service from Cocoon 2.1.5,
with little joy.
I noticed various discussions on the wiki and the dev list about your source
writing idea and some other options from Daniel Fagerstrom and Steve Punte.
Do you know what the current preferred method is to call a Web service from
Cocoon
Christian Mayrhuber wrote:
On Monday 26 July 2004 16:12, Daniel Fagerstrom wrote:
I'm currently writing a hand crafted stub for a remote object, that I can use
in both Flowscript and my custom generator. (The remote side has no wsdl)
If the remote site had a wsdl description you could use
Antonio Fiol Bonnín wrote:
Hello,
We have started developing two extensions for cocoon, and we would
like to know if the core team would be interested in getting them into
the trunk, and optionally in maintaining them in the future.
The extensions are:
- A transformer that connects via HTTP POST
Antonio Fiol Bonnín wrote:
I have implemented something like that, see:
http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. It is not yet
part of Cocoon as we have differing opinions about the design as you can
see in the Bugzilla entry and also in the thread:
Guido Casper wrote:
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the configuration more complex
Pier Fumagalli wrote:
snip/
As I personally need the kernel, I will personally invest some more
time into it, Cocoon or not (frankly, I could care less at this point).
I think that the current kernel code is wrong, as it's based on
implementation of interfaces a-la Avalon, and you showed me a
Sylvain Wallez wrote:
snip/
Instead of creating yet-another-small-project at cocoondev.org (like
my own CVSSource), what about creating a general-purpose project that
would host all interesting cocoon-releated things we cannot host at
the ASF because of license problems?
Instead of having a
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
While I agree with your concerns, I think a DI container can
_potentially_ bring a lot in this area. The current problem with
Cocoon's xconf file is that it is really free-form, and the variety of
the components makes writing an XML grammar
Ugo Cei wrote:
Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
data. In Spring you must as well supply wiring information about how
the component is connected to other components thru setters. You need
to describe the life cycle, if there are any initialization and
destruction
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Add your reasons.
Since Avalon came to life and I came to love it, I've had long fights
with some of my colleagues at work to convince them to use it, in
order to have robust architectures. Their argument was that they
didn't want to use
Carsten Ziegeler wrote:
I just started with this approach and could finish it in the next days
if people think it is worth going this way. It would give 2.2 more meat
as well.
But perhaps this idea is totally foolish?
Thoughts? Comments?
+1
Seem like a very reasonable way to go, we both takes
Carsten Ziegeler wrote:
I already committed the first version of ECM++ into the whiteboard.
Now, the question is how do we want to continue?
I already integrated it into 2.2 on my computer. It requires only a few
changes in Cocoon.java and in some treeprocessor classes.
Should I switch 2.2 to use
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
Yes, in general you're right, but readding Composable etc. is
nearly the same work then refactoring XSP which should be very
simple. So I would opt for saving the extra work of readding things.
Sounds reasonable, do what you find best
Frédéric Glorieux wrote:
Request reader and this
map:read src=module:request:inputStream/
works as well. This writing is nice, I like it.
Is there some more samples of those things ?
You can find some samples in:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
But we have to define the behavior of getInputStream for environments
where it has no meaning (e.g. background env,
It can be initialized with java.io.InputStream (File, byte array), or
null. If null, throw exception.
sitemap source, cocoonbean
I
Tony Collen wrote:
To my knowledge, the PHPGenerator hasn't worked for quite some time.
In all the time I've been working with Cocoon, I have never seen it
work correctly.
However, I believe the problem is within the PHP Servlet itself,
which, if you do some research, tons of people have had
Torsten Curdt wrote:
Folks please cast your votes for:
[ ] Leszek
[ ] Ralph
+1 for both!
/Daniel
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while Jexl is
mostly useless in that case but is straightforward when you deal
with JavaBeans. I also agree that understanding the difference
between ${continuation.id} and
Reinhard Poetz wrote:
After a lot of mails talking about expression languages and templating
enginges I try to summarize the current state of our discussion. I
see following requirements so far (in brackets you find the name of
the person that brought up the requirement):
- control
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
E.) Use Jelly: http://jakarta.apache.org/commons/jelly/
AFAIK Jelly allready solve most of the requirements above.
More specifically it uses JEXL or Jaxen as expression
language, and you can use expressions both in attributes and
in text
Bart Molenkamp wrote:
I've also been thinking about a simple method for displaying object
instances of different classes. E.g. I get an object from the flow
layer, I need to decide how to format it. Instances of class A are
formatted differently than instances from class B. Now, this could be
done
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I have done some work on implementing a Jelly generator.
Basically my own versions of the JellyGenerator in scratchpad
and your TemplateObjectModelHelper, didn't know the existence
of either of them :/
The most irritating problem that I have
Jonas Ekstedt wrote:
On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote:
Ok, the idea is as follows: we have a converter component, that is like
the renderer component above, but bidirectional. I.e. both rendering:
data type - displayable string and input conversion: input string
Jonas Ekstedt wrote:
On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote:
Ok, the idea is as follows: we have a converter component, that is like
the renderer component above, but bidirectional. I.e. both rendering:
data type - displayable string and input conversion: input string
Jonas Ekstedt wrote:
On Wed, 2004-11-03 at 21:46 +0100, Daniel Fagerstrom wrote:
snip/
In some cases like when you
can build lists or trees in the user interface, a more traversal based
interface is needed.
I agree that I haven't really thought this issue through thoroughly. In
the widget
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
In the (often cited on this list) article: Enforcing Strict Model
View Separation in Template Engines, by Terence Parr
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, a number of
rules for strict separation between model and view
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
What that means is that a convertor should be able to do the
following conversions:
- string+locale -- object : parsing request parameters
- object+locale -- string : producing the value of an input
- object+locale+channel -- xml fragment : producing
Jonas Ekstedt wrote:
On Fri, 2004-11-05 at 14:02 +0100, Daniel Fagerstrom wrote:
If I would be able to choose convertors I might decide IN VIEW ITSELF
that that specific model value should be coloured/pretty
printed/rendered according to some specific logic. As long as this
logic has read
, 5 Nov 2004 17:54:25 -0800
From: Terence Parr [EMAIL PROTECTED]
To: Daniel Fagerstrom [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
On Nov 5, 2004, at 5:27 AM, Daniel Fagerstrom wrote:
Hi Terence!
I have read your article: Enforcing Strict Model View Separation in
Template Engines with great
I'll give some short comments now. Hope to find time to give a more
detailed view about multiform handling and other stuff later.
Jonas Ekstedt wrote:
snip/
I tried to implement a RequestProcessor for CForms just to see if it was
doable.
Cool!
It doesn't yet work quite the way you envision with
Jonas Ekstedt wrote:
On Sat, 2004-11-06 at 16:13 +0100, Daniel Fagerstrom wrote:
Please submit your patch to Bugzilla so that it doesn't get lost among
all the mails. See http://wiki.apache.org/cocoon/ProjectManagement for
instructions. It is also good to have a Bugzilla entry so that you can
Jonas Ekstedt wrote:
On Mon, 2004-11-08 at 14:10 +0100, Leszek Gawron wrote:
Something like ${bean.startDate} or jx:out value=${bean.startDate}/ would
use default renderer. Something like ${bean.startDate?class=emph} jx:out
value=${bean.startDate} styling=emph/ would point that other
I took a look at the Rhino download page
http://www.mozilla.org/rhino/download.html and found to my suprise that
Rhino 1.6R1 (the version that we use in the trunk) includes ECMAScript
for XML (E4X). That makes XML a native data type in JS and let you do
XPath like things within the JS syntax,
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
http://domify.sourceforge.net/ ?
Hmm, I have to take a look at that (if I have time for it...).
I took a look at Domify some time ago when trying to implement some of
the ideas in the Search for the perfect template language RT. It
seemed
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
I took a look at the Rhino download page
http://www.mozilla.org/rhino/download.html and found to my suprise
that Rhino 1.6R1 (the version that we use in the trunk) includes
ECMAScript for XML (E4X). That makes XML a native data type in JS and
let
Luca Garulli wrote:
On Wed, 10 Nov 2004 17:17:05 +0100, Luca Garulli [EMAIL PROTECTED] wrote:
Daniel Fagerstrom dijo:
I took a look at the Rhino download page
http://www.mozilla.org/rhino/download.html and found to my suprise that
Rhino 1.6R1 (the version that we use in the trunk
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
I have looked a little bit more on it. It doesn't seem to work with
the Rhino jar in the SVN. Rhino recognize the E4X syntax but it
cannot find the XML class that is needed. The xbean.jar must be
present during compilation AFAICS, probably our
I planed to use some stuff in scratchpad for development. As I have a
slow computer at home I always remove all blocks that I don't need to
decrase compile time and startup time.
The tree below describe everything that the scratchpad block depend on.
And this is without samples dependencies.
Micah Dubinko wrote:
snip/
I'm happy to learn whatever I can here.
snip/
Micah Dubinko wrote in another mail:
I want to get involved in Cocoon more, and wonder if this would be a
good project to cut my teeth on.
Hi Micah (and the rest of the list)!
There are certainly places in Cocoon where your
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
After this experience and especially after Sylvain's letter, there
seem to have been a feeling in the community that XForms is not
relevant for Cocoon.
Let me correct this: in the now famous XMLForms vs Woody post, the
conclusion wasn't
Torsten Curdt wrote:
snip/
Exactly! For a secure system we need to keep the indirect population
approach. Although I had some continuation related RT on this...
What actually is suspected to be populated on the next request
is available through the result of the last continuation!
Given this
Reinhard Poetz wrote:
--- Sylvain Wallez [EMAIL PROTECTED] schrieb:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Sorry to rain on the party, but the new widget
state stuff in CForms
should make building multi-page forms a piece of
cake.
Off writing an example
Done, I
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=32169
where I have enhanced work of Jonas Ekstedt so that one can do the
kind of things you asked for in the section about multi page forms in
http://marc.theaimsgroup.com/?l
Jonas Ekstedt wrote:
On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
CForms Convertor Integration
snip/
How about an interface like this:
public interface Convertor {
public String getId();
public void setId(String id);
public Class
1 - 100 of 1344 matches
Mail list logo
