You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2003/07/07 01:36:43 UTC
All scratchpad code migrated to FOM
I just modified the remainder of the scratchpad code including PetStore
and JXForms to use the FOM. I also implemented the FOM WebContinuation.
However, in order not to break anyone immediately who may be using them,
I haven't yet modified the JXTemplateGenerator and FlowVelocityGenerator
to use the FOM. The XMLForm, Woody, and Linotype blocks will still need
to be modified before we can blast the old flow implementation. In
addition, the core Flowscript samples and documentation will need to be
updated.
Regards,
Chris
Re: JXTemplate* and FOM moved to core
Posted by Steven Noels <st...@outerthought.org>.
On 8/07/2003 8:03 Christopher Oliver wrote:
> I've moved the FOM implementation and JXTemplate* to the core. For now
> I've left the original flow implementation in place as a second
> interpreter, so Woody, Linotype, XMLForm, and the Flow samples will
> continue to work without change until we can migrate them. Petstore,
> JXForms, and Garbage are still in the scratchpad but have been updated
> to use FOM. For the moment, the new FOM interpreter is called
> "javascript", and the original interpreter is still called "JavaScript".
>
> To me the most important next step is to update the documentation, so
> that's what I'll try to do when I have time.
Thanks, Chris!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: JXTemplate* and FOM moved to core (was: Re: All scratchpad code migrated to FOM)
Posted by Reinhard Pötz <re...@gmx.net>.
From: Christopher Oliver
> I've moved the FOM implementation and JXTemplate* to the
> core. For now
> I've left the original flow implementation in place as a second
> interpreter, so Woody, Linotype, XMLForm, and the Flow samples will
> continue to work without change until we can migrate them. Petstore,
> JXForms, and Garbage are still in the scratchpad but have
> been updated
> to use FOM. For the moment, the new FOM interpreter is called
> "javascript", and the original interpreter is still called
> "JavaScript".
Sounds good!
>
> To me the most important next step is to update the documentation, so
> that's what I'll try to do when I have time.
Okay.
I going to help on Thursday and on Friday with documentation and
changes to FOM to make everything ready for beta release.
Regards,
Reinhard
>
> Regards,
>
> Chris
>
> Reinhard Pötz wrote:
>
> >From: Christopher Oliver
> >
> >
> >
> >>I just modified the remainder of the scratchpad code including
> >>PetStore and JXForms to use the FOM. I also implemented the FOM
> >>WebContinuation.
> >>However, in order not to break anyone immediately who may be
> >>using them,
> >>I haven't yet modified the JXTemplateGenerator and
> >>FlowVelocityGenerator
> >>to use the FOM. The XMLForm, Woody, and Linotype blocks will
> >>still need
> >>to be modified before we can blast the old flow implementation.
> >>
> >>
> >
> >After the vote we can start to update the blocks and the two
> >generators
> >(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=10575729452
6615&w=2)
>
>So Chris (and of course everybody else who is interessted) we can go
for
>it!
>(http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.)
>I can help on Thursday at the earliest.
>
>
>If anybody knows of open points please let me know!
>
>
>I'll start the vote on the Flow (in general) and the JavaScript/FOM
>implementation
>ASAP!
>
>Cheers,
>Reinhard
>
>
>
>
JXTemplate* and FOM moved to core (was: Re: All scratchpad code migrated
to FOM)
Posted by Christopher Oliver <re...@verizon.net>.
I've moved the FOM implementation and JXTemplate* to the core. For now
I've left the original flow implementation in place as a second
interpreter, so Woody, Linotype, XMLForm, and the Flow samples will
continue to work without change until we can migrate them. Petstore,
JXForms, and Garbage are still in the scratchpad but have been updated
to use FOM. For the moment, the new FOM interpreter is called
"javascript", and the original interpreter is still called "JavaScript".
To me the most important next step is to update the documentation, so
that's what I'll try to do when I have time.
Regards,
Chris
Reinhard Pötz wrote:
>From: Christopher Oliver
>
>
>
>>I just modified the remainder of the scratchpad code
>>including PetStore
>>and JXForms to use the FOM. I also implemented the FOM
>>WebContinuation.
>>However, in order not to break anyone immediately who may be
>>using them,
>>I haven't yet modified the JXTemplateGenerator and
>>FlowVelocityGenerator
>>to use the FOM. The XMLForm, Woody, and Linotype blocks will
>>still need
>>to be modified before we can blast the old flow implementation.
>>
>>
>
>After the vote we can start to update the blocks and the two
>generators
>(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105757294526615&w=2)
>
>So Chris (and of course everybody else who is interessted) we can go for
>it!
>(http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.)
>I can help on Thursday at the earliest.
>
>
>If anybody knows of open points please let me know!
>
>
>I'll start the vote on the Flow (in general) and the JavaScript/FOM
>implementation
>ASAP!
>
>Cheers,
>Reinhard
>
>
>
>
RE: All scratchpad code migrated to FOM
Posted by Reinhard Pötz <re...@gmx.net>.
From: Christopher Oliver
> I just modified the remainder of the scratchpad code
> including PetStore
> and JXForms to use the FOM. I also implemented the FOM
> WebContinuation.
> However, in order not to break anyone immediately who may be
> using them,
> I haven't yet modified the JXTemplateGenerator and
> FlowVelocityGenerator
> to use the FOM. The XMLForm, Woody, and Linotype blocks will
> still need
> to be modified before we can blast the old flow implementation.
After the vote we can start to update the blocks and the two
generators
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105757294526615&w=2)
So Chris (and of course everybody else who is interessted) we can go for
it!
(http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow.)
I can help on Thursday at the earliest.
If anybody knows of open points please let me know!
I'll start the vote on the Flow (in general) and the JavaScript/FOM
implementation
ASAP!
Cheers,
Reinhard
Re: Fixing module confusion (was Re: All scratchpad code migrated
Posted by Upayavira <uv...@upaya.co.uk>.
On 9 Jul 2003 at 15:25, Geoff Howard wrote:
> Ok, thanks - will do. I'll make a README.txt and send it with the
> request.
Or email Pier directly, and he can do it...
[He did offer, and said he won't be reading the list for a few weeks].
Regards, Upayavira
Re: Fixing module confusion (was Re: All scratchpad code migrated
to FOM)
Posted by Geoff Howard <co...@leverageweb.com>.
Ok, thanks - will do. I'll make a README.txt and send it with the request.
Geoff
Vadim Gritsenko wrote:
> Geoff Howard wrote:
>
>> We discussed this reoccuring problem recently and there was a sort of
>> consensus (http://marc.theaimsgroup.com/?t=105623361100002&r=1&w=2) to
>> remove the link which currently exists from xml-cocoon2 to the
>> "historical" cocoon module and in its place create a real module at
>> xml-cocoon2 which contains only one README.txt containing an
>> explanation of the real module names.
>>
>> I don't think I have the karma to do this myself without intervention
>> or I would have done it by now. Does this have to go through
>> infrastructure or is there someone here who can do that?
>
>
>
> Only cvsadmin can do this:
>
> drwxrwxr-x 189 root cvsadmin 4608 Jul 2 00:58 ./
> lrwxrwxr-x 1 pier cvsadmin 19 Feb 26 18:23 xml-cocoon2@ ->
> cocoon-2-historical
>
> Please send a request to the infrastructure team.
>
Re: Fixing module confusion (was Re: All scratchpad code migrated
to FOM)
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
> We discussed this reoccuring problem recently and there was a sort of
> consensus (http://marc.theaimsgroup.com/?t=105623361100002&r=1&w=2) to
> remove the link which currently exists from xml-cocoon2 to the
> "historical" cocoon module and in its place create a real module at
> xml-cocoon2 which contains only one README.txt containing an
> explanation of the real module names.
>
> I don't think I have the karma to do this myself without intervention
> or I would have done it by now. Does this have to go through
> infrastructure or is there someone here who can do that?
Only cvsadmin can do this:
drwxrwxr-x 189 root cvsadmin 4608 Jul 2 00:58 ./
lrwxrwxr-x 1 pier cvsadmin 19 Feb 26 18:23 xml-cocoon2@ ->
cocoon-2-historical
Please send a request to the infrastructure team.
Vadim
Fixing module confusion (was Re: All scratchpad code migrated to
FOM)
Posted by Geoff Howard <co...@leverageweb.com>.
We discussed this reoccuring problem recently and there was a sort of
consensus (http://marc.theaimsgroup.com/?t=105623361100002&r=1&w=2) to
remove the link which currently exists from xml-cocoon2 to the
"historical" cocoon module and in its place create a real module at
xml-cocoon2 which contains only one README.txt containing an explanation
of the real module names.
I don't think I have the karma to do this myself without intervention or
I would have done it by now. Does this have to go through
infrastructure or is there someone here who can do that?
Geoff
Jacob L E Blain Christen wrote:
>>I just compiled a clean checkout with jdk1.4.1_01 on windows 2000
>>without problems including the scratchpad. What error did you encounter?
>>If it was with FlowVelocityGenerator, then you need to update from the
>>latest cvs.
>
>
> I was compiling code originally checked out of HEAD when cocoon's
> cvs module name was "xml-cocoon" (I'd been running cvs update
> periodically) and I realized after hitting send on my email that
> perhaps I wasn't checking out the relevant module any longer.
> So, I referred to the installation howto once again: lo and behold
> it seems "cocoon-2.1" is where the "current" version of cocoon lives.
> I am checking that out now (slow connection, heh) and will let you
> know if I run into an problems (I do not forsee any).
>
> --
> Jacob
>
>
>
RE: All scratchpad code migrated to FOM
Posted by Jacob L E Blain Christen <ja...@entheal.com>.
> I just compiled a clean checkout with jdk1.4.1_01 on windows 2000
> without problems including the scratchpad. What error did you encounter?
> If it was with FlowVelocityGenerator, then you need to update from the
> latest cvs.
I was compiling code originally checked out of HEAD when cocoon's
cvs module name was "xml-cocoon" (I'd been running cvs update
periodically) and I realized after hitting send on my email that
perhaps I wasn't checking out the relevant module any longer.
So, I referred to the installation howto once again: lo and behold
it seems "cocoon-2.1" is where the "current" version of cocoon lives.
I am checking that out now (slow connection, heh) and will let you
know if I run into an problems (I do not forsee any).
--
Jacob
Re: All scratchpad code migrated to FOM
Posted by Christopher Oliver <re...@verizon.net>.
I just compiled a clean checkout with jdk1.4.1_01 on windows 2000
without problems including the scratchpad. What error did you encounter?
If it was with FlowVelocityGenerator, then you need to update from the
latest cvs.
Chris
Jacob L E Blain Christen wrote:
>>I just modified the remainder of the scratchpad code including PetStore
>>and JXForms to use the FOM. I also implemented the FOM WebContinuation.
>>However, in order not to break anyone immediately who may be using them,
>>I haven't yet modified the JXTemplateGenerator and FlowVelocityGenerator
>>to use the FOM. The XMLForm, Woody, and Linotype blocks will still need
>>to be modified before we can blast the old flow implementation. In
>>addition, the core Flowscript samples and documentation will need to be
>>
>>
>
>ahh, is this why the current build dies on the compile-scratchpad
>target ?
>
>
>
RE: All scratchpad code migrated to FOM
Posted by Jacob L E Blain Christen <ja...@entheal.com>.
> I just modified the remainder of the scratchpad code including PetStore
> and JXForms to use the FOM. I also implemented the FOM WebContinuation.
> However, in order not to break anyone immediately who may be using them,
> I haven't yet modified the JXTemplateGenerator and FlowVelocityGenerator
> to use the FOM. The XMLForm, Woody, and Linotype blocks will still need
> to be modified before we can blast the old flow implementation. In
> addition, the core Flowscript samples and documentation will need to be
ahh, is this why the current build dies on the compile-scratchpad
target ?