/show_bug.cgi?id=14449
Dynamic models in XMLForms
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
/show_bug.cgi?id=18487
Several minor bugs in XMLForms Howto
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
/show_bug.cgi?id=18487
Several minor bugs in XMLForms Howto
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
/show_bug.cgi?id=18487
Several minor bugs in XMLForms Howto
Summary: Several minor bugs in XMLForms Howto
Product: Cocoon 2
Version: Current CVS
Platform: All
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
/show_bug.cgi?id=18487
Several minor bugs in XMLForms Howto
--- Additional Comments From [EMAIL PROTECTED] 2003-03-29 03:39 ---
Created an attachment (id=5559)
Fixes abovementioned problems
4:50 PM
Subject: more xmlforms + schematron, why ?
Looking at xmlforms and schematron more closely, I'm starting to
wonder why this combination was chosen anyways? from the examples
it seems the purpose of schematrons is to validate input fields, but
checking
something simple as if a field
Hello all :)
I've got a problem, first the context :
Xmlforms uses schematrons to validate forms, if I'm not mistaken the
parsing/applying of schematron xml files is done in the xmlforms java code.
It seems that schematron 'abstract rules' as specified for example in:
http://www.zvon.org/ZvonSW
Looking at xmlforms and schematron more closely, I'm starting to
wonder why this combination was chosen anyways? from the examples
it seems the purpose of schematrons is to validate input fields, but checking
something simple as if a field is only alpha characters seems to be near
impossible
]
To: [EMAIL PROTECTED]
Sent: Thursday, March 13, 2003 4:50 PM
Subject: more xmlforms + schematron, why ?
Looking at xmlforms and schematron more closely, I'm starting to
wonder why this combination was chosen anyways? from the examples
it seems the purpose of schematrons is to validate input fields
Looking at xmlforms and schematron more closely, I'm starting to
wonder why this combination was chosen anyways? from the examples
it seems the purpose of schematrons is to validate input fields, but checking
something simple as if a field is only alpha characters seems to be near
impossible
schematron and don't use it - so I don't
have anything at hand :) But you might wanna have a look into the
translate function
Is Schematron the only Schema language you can use with XMLForms?
regards Jeremy
schematron and don't use it - so I don't
have anything at hand :) But you might wanna have a look into the
translate function
Is Schematron the only Schema language you can use with XMLForms?
regards Jeremy
Guido Casper [EMAIL PROTECTED] wrote:
Sent: Thursday, March 13, 2003 10:24 AM
To: [EMAIL PROTECTED]
Subject: Re: more xmlforms + schematron, why ?
I agree, that the lack of support for regular expressions is
the biggest obstacle to schematron use.
I wonder if anybody is already
:
Subject: more xmlforms + schematron,
why ?
03/13/03 07:50 AM
Please respond
PROTECTED]
Sent: Thursday, March 13, 2003 11:34 AM
Subject: Re: more xmlforms + schematron, why ?
On Thursday, March 13, 2003, at 04:50 PM, Torsten Curdt wrote:
and if anyone does have a simple idea of how to do a simple check
with schematron for alpha or non alpha strings ( 'test' is good
Hi again, sorry for the delay.
massive snip/
Having used cocoon and OJB for no less than four (4) of our projects
I can only say that the combination of flow + OJB really makes life
easier. We´re using OJB by reversing the db into an OJB-mapping file
for which we generate beans that in turn
Antonio Gallardo wrote:
Hi!
After seeing how Christian and Ugo greatly done the relation between
XMLForms and Flow.
A Bean is the model of the MVC, XMLForm the View and Flow the controller.
A short of this can be B-XMLF-F. :-)
Now still stay in the air the question of how to handle the down side
Sorry for the really sloppy snip, Stefano and Antonio.
Didn´t mean to distort your orginal messages.
regards,
Per-Olof Norén
On Saturday, March 1, 2003, at 10:23 AM, Per-Olof Norén wrote:
Sorry for the really sloppy snip, Stefano and Antonio.
Didnt mean to distort your orginal messages.
We'll forgive you
..
as long as you write up some stuff on using Apache OJB with XForms +
Flow ;)
Sorry, only joking ;)
Per-Olof Norén wrote:
Stefano Mazzocchi wrote:
First of I´d like to say that we decided not to used XMLForms in favor
of pure flowscript, since we´re building large business applications.
Despite the direction change we took, I really appriciate the XMLForms...
snip/
I know Ugo likes
Sure the flowscript layer can (and will, I'm sure) be abused, but as
much as ant build files, or sitemaps can reach a point where the mess
and performance drags you down and refactoring is needed.
Since you did bring it up... ;)
Could you offer some tips on how to refactor an ant build script
Jason Foster wrote:
Sure the flowscript layer can (and will, I'm sure) be abused, but as
much as ant build files, or sitemaps can reach a point where the mess
and performance drags you down and refactoring is needed.
Since you did bring it up... ;)
Could you offer some tips on how to refactor
I have done the
example off the site for XMLForms.
Having got this to
work i have tried to create a new form. I want to put a dropdown list in but
have no idea what the code is.
Is coding for
XMLForms the same as XForms, so in this case i would do a
select1?
Im sure there is
going
Am Fre, 2003-02-28 um 14.22 schrieb [EMAIL PROTECTED]:
I have done the example off the site for XMLForms.
Having got this to work i have tried to create a new form. I want to
put a dropdown list in but have no idea what the code is.
Is coding for XMLForms the same as XForms, so in this case
Hi!
After seeing how Christian and Ugo greatly done the relation between
XMLForms and Flow.
A Bean is the model of the MVC, XMLForm the View and Flow the controller.
A short of this can be B-XMLF-F. :-)
Now still stay in the air the question of how to handle the down side of
the persistent
Hello, Konstantin.
...
Having the model declaration in the sitemap is not a very good idea IMHO.
In
a real application there are a lot of forms and each one has its own
model.
Having all these declared in the sitemap would make a hybrid monster from
it.
...
I agree. The solution proposed
Hi!
Just to add my i18n:currency value=0.02/.
Having the model declaration in the sitemap is not a very good idea IMHO. In
a real application there are a lot of forms and each one has its own model.
Having all these declared in the sitemap would make a hybrid monster from
it.
What would be more
On 15.Feb.2003 -- 07:02 PM, Sylvain Wallez wrote:
What would be a real killer feature is a SQL model : no more java coding
to edit/update your database from XMLForm (I must say having to write
extensive JavaBean code refrained me to use it up to now).
I believe both operation models are
Christian Haul wrote:
On 15.Feb.2003 -- 07:02 PM, Sylvain Wallez wrote:
What would be a real killer feature is a SQL model : no more java coding
to edit/update your database from XMLForm (I must say having to write
extensive JavaBean code refrained me to use it up to now).
I believe
On 17.Feb.2003 -- 11:11 AM, Sylvain Wallez wrote:
Wow, looks cool, but the configuration road starts looking like a
configurration maze...
Well, yes :-(
But if there is enough interest, the actions could receive support for
passing the form id dynamically so that steps b) and c) would not be
Christian Haul wrote:
On 17.Feb.2003 -- 11:11 AM, Sylvain Wallez wrote:
Wow, looks cool, but the configuration road starts looking like a
configurration maze...
Well, yes :-(
But if there is enough interest, the actions could receive support for
passing the form id dynamically so that
Thanks for the comments.
I will read up some more and decide whether it may work for a huge
meet-in-the-middle project.
-=Ivelin=-
- Original Message -
From: Ugo Cei [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, February 16, 2003 3:32 AM
Subject: Re: extending XMLForms
]
To: [EMAIL PROTECTED]
Sent: Sunday, February 16, 2003 7:06 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?
hi all,
Am Son, 2003-02-16 um 10.32 schrieb Ugo Cei:
ivelin wrote:
Ugo, can you can share experience with Hibernate vs. Jakarta OJB,
Cayenne
or another
ivelin wrote:
Ugo, can you can share experience with Hibernate vs. Jakarta OJB, Cayenne
or another Open Source O/R tool.
There is a reasonably objective comparison here
http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
but I would like to hear more from a usability, flexibility and
hi all,
Am Son, 2003-02-16 um 10.32 schrieb Ugo Cei:
ivelin wrote:
Ugo, can you can share experience with Hibernate vs. Jakarta OJB, Cayenne
or another Open Source O/R tool.
There is a reasonably objective comparison here
http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
Jakob Praher wrote:
In my experience, using a simple Bean Object as the form model and then
using this model to fill in a DataObject is the better approach than
direct binding the data object to the form, as you can't always do a 1:1
mapping between all the fields.
This is a good point. In my
On Sunday 16 February 2003 03:49, Christopher Oliver wrote:
Just wondering, why isn't the average cocoon user reluctant to write
complex xpath or xslt code as well as Java?
People, there is NO average Cocoon user. Please refer to the SoC diagram at
PROTECTED]
Sent: Friday, February 14, 2003 7:07 AM
Subject: extending XMLForms for different kinds of models...opinions?
Dear all,
I need your suggestions and opinions in extending the current XMLForm
model
approach. If you use XMLForm or are thinking about using it soon, I'd
suggest youy to read
ivelin wrote:
This sounds good.
As you suggest the java: prefix can be used for instantiating JavaBeans.
For all other cases though, I was hoping to reuse the standard
SourceResolver.
This will immediately allow support for a lot of different sources.
Here is a snippet from the Sitemap document.
snip/
Mmmmh. I think the SourceResolver should be _one_ of the possible
models, and not the default one if something else than java is used.
What would be a real killer feature is a SQL model : no more java
coding to edit/update your database from XMLForm (I must say having to
write extensive
Bernhard Huber wrote:
snip/
Mmmmh. I think the SourceResolver should be _one_ of the possible
models, and not the default one if something else than java is
used. What would be a real killer feature is a SQL model : no more
java coding to edit/update your database from XMLForm (I must say
Just wondering, why isn't the average cocoon user reluctant to write
complex xpath or xslt code as well as Java?
Regards,
Chris
Sylvain Wallez wrote:
This is a good idea when you need to use the JavaBean for some
business logic. But there are many cases where you just want to
populate a
Sylvain Wallez wrote:
This is a good idea when you need to use the JavaBean for some business
logic. But there are many cases where you just want to populate a
database after successful validation, and the average Cocoon user
quickly becomes reluctant to writing Java code, even for storing
Christopher Oliver wrote:
Just wondering, why isn't the average cocoon user reluctant to write
complex xpath or xslt code as well as Java?
Because Cocoon makes it so easy to write very powerful things with
simple xpath and xslt, that having to go back to a compiler and
deploying classes is
Ugo Cei wrote:
Sylvain Wallez wrote:
This is a good idea when you need to use the JavaBean for some
business logic. But there are many cases where you just want to
populate a database after successful validation, and the average
Cocoon user quickly becomes reluctant to writing Java code,
Sylvain Wallez dijo:
Ugo Cei wrote:
Sylvain Wallez wrote:
This is a good idea when you need to use the JavaBean for some
business logic. But there are many cases where you just want to
populate a database after successful validation, and the average
Cocoon user quickly becomes reluctant to
perspective.
-=Ivelin=-
- Original Message -
From: Ugo Cei [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 15, 2003 2:41 PM
Subject: Re: extending XMLForms for different kinds of models...opinions?
Sylvain Wallez wrote:
This is a good idea when you need to use the JavaBean
Ditto.
-=Ivelin=-
- Original Message -
From: Josema Alonso [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 15, 2003 11:41 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?
Ivelin,
That sounds very very good. I was not sure about all
: Christopher Oliver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 15, 2003 1:49 PM
Subject: Re: extending XMLForms for different kinds of models...opinions?
Just wondering, why isn't the average cocoon user reluctant to write
complex xpath or xslt code as well as Java?
Regards
Our company is currently building a project around cocoon(yay:) and xmlforms.
We are using the current development cvs version.
Working on this it occured to me that the prepare and perform methods of
the AbstractXMLFormAction class don't allow the throwing of any exceptions
whatsoever.
My
Am Don, 2003-02-13 um 17.20 schrieb Jeroen Cranendonk:
Our company is currently building a project around cocoon(yay:) and xmlforms.
We are using the current development cvs version.
Working on this it occured to me that the prepare and perform methods of
the AbstractXMLFormAction class don't
Am Don, 2003-02-13 um 17.20 schrieb Jeroen Cranendonk:
Our company is currently building a project around cocoon(yay:) and
xmlforms.
We are using the current development cvs version.
Working on this it occured to me that the prepare and perform methods of
the AbstractXMLFormAction class
Am Don, 2003-02-13 um 19.17 schrieb Jeroen Cranendonk:
Am Don, 2003-02-13 um 17.20 schrieb Jeroen Cranendonk:
Our company is currently building a project around cocoon(yay:) and
xmlforms.
We are using the current development cvs version.
Working on this it occured to me
: Jeroen Cranendonk [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 10:20 AM
Subject: XMLForms prepare/perform nothrow
Our company is currently building a project around cocoon(yay:) and
xmlforms.
We are using the current development cvs version.
Working on this it occured
Sorry for the delay.
XML source doc attached.
- Original Message -
From: Tom Amiro [EMAIL PROTECTED]
To: Ivelin Ivanov [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Santiago Pericas-Geertsen
[EMAIL PROTECTED]
Sent: Monday, November 18, 2002 8:06 AM
Subject: Re: [XMLFORMS exception] was Re
Sorry. I must have made a mistake cutting and pasting. The
snippets are the same.
Tom
Tom Amiro wrote:
Hi,
The html produced by Xalan vs XSLTC are so different, it is hard to know
where to begin.
It definitely looks like an XSLTC bug.
Below are snippets from the top showing that
Hi,
Santiago has started looking at the problem with XSLTC.
It would help if you could send some XML source.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Hi,
The html produced by Xalan vs XSLTC are so different, it is hard to know
where to begin.
It definitely looks like an XSLTC bug.
Below are snippets from the top showing that things get out of synch
really fast.
It would help in debugging this, if you could simplify the xsl and
provide a
What's different? ;-)
Joerg
Tom Amiro wrote:
Hi,
The html produced by Xalan vs XSLTC are so different, it is hard to know
where to begin.
It definitely looks like an XSLTC bug.
Below are snippets from the top showing that things get out of synch
really fast.
It would help in debugging this,
Thanks for the notice.
I reproduced the problem.
Will post again when it is fixed.
- Original Message -
From: Ramy Mamdouh [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 15, 2002 5:53 AM
Subject: [XMLFORMS exception] was Re: Exception with current CVS of 2.1
Hi
Subject: [XMLFORMS exception] was Re: Exception with current CVS of 2.1
Hi
using the latest xerces with xmlforms (either mine or the wizard sample)
resulted in :
/org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.util.EmptyStackException/
Original exception
On Saturday, Nov 16, 2002, at 18:58 Europe/London, Ivelin Ivanov wrote:
Until now all XMLForm demo pages have been working equally good with
both
XSLTC and Xalan.
I will now have to switch the demo to Xalan until this difference in
the
translators is resolved.
One thing I noticed recently,
Hi
using the latest xerces with xmlforms (either mine or the wizard sample)
resulted in :
/org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.util.EmptyStackException/
Original exception : java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:82
/show_bug.cgi?id=14449
Dynamic models in XMLForms
Summary: Dynamic models in XMLForms
Product: Cocoon 2
Version: Current CVS
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component
/show_bug.cgi?id=14450
Dynamic models in XMLForms
Summary: Dynamic models in XMLForms
Product: Cocoon 2
Version: Current CVS
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component
/show_bug.cgi?id=14450
Dynamic models in XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-11-11 19:21 ---
*** Bug 14449 has been marked as a duplicate of this bug. ***
-
To unsubscribe, e-mail: [EMAIL PROTECTED
/show_bug.cgi?id=14449
Dynamic models in XMLForms
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
/show_bug.cgi?id=12721
xmlform2html.xsl (XMLForms example) templates bad markup for textboxes
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|VERIFIED|CLOSED
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-28 19:45 ---
Patch Commited.
Thank you Simon and Konstantin.
The next desired feature is i18n demo
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
Summary: [PATCH] new help and hint elements for XMLForms
Product: Cocoon 2
Version: Current CVS
Platform: All
URL: http://localhost:8080/cocoon/samples/xmlform/wizard
OS
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 09:38 ---
Created an attachment (id=3256)
zipped up patch files for HELP and HINT XMLForms elements
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 09:40 ---
A minor suggestion: another possibility is to use the 'title' attribute for
form elements to display the hint
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 13:04 ---
I meant the 'title' attribute of HTML elements. E.g.:
xf:text
...
xf:hintClick to continue/xf:hint
/xf:text
could be transformed to (HTML):
input
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 13:09 ---
Thanks for the clarification.
I like the 'title' idea now. I will use it instead of the javascript.
Is that ok with you Simon?
Since checkbox is still
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 15:06 ---
I like the 'title' idea now. I will use it instead of the javascript.
Is that ok with you Simon?
Yeah - that's what I wanted to do in the first place
/show_bug.cgi?id=13066
[PATCH] new help and hint elements for XMLForms
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 15:22 ---
Also, we still have the selectBoolean for a single check-box.
Do you know what XForms recommends for a check-box, or they still don't have a
suggestion
/show_bug.cgi?id=12986
XMLForms: Form class locate() loses order of nodes in returned Set
Summary: XMLForms: Form class locate() loses order of nodes in
returned Set
Product: Cocoon 2
Version: Current CVS
Platform: All
OS/Version
/show_bug.cgi?id=12986
XMLForms: Form class locate() loses order of nodes in returned Set
--- Additional Comments From [EMAIL PROTECTED] 2002-09-25 05:46 ---
Created an attachment (id=3211)
Patch to use LinkedHashSet instead of HashSet when creating return Set for
Form.locate(String
/show_bug.cgi?id=12721
xmlform2html.xsl (XMLForms example) templates bad markup for textboxes
--- Additional Comments From [EMAIL PROTECTED] 2002-09-21 22:37 ---
Fixed xslt to produce text instead of textbox in the html
/show_bug.cgi?id=12721
xmlform2html.xsl (XMLForms example) templates bad markup for textboxes
Summary: xmlform2html.xsl (XMLForms example) templates bad markup
for textboxes
Product: Cocoon 2
Version: Current CVS
Platform: All
OS
Implementation now available in CVS HEAD for Cocoon 2.1.
- Original Message -
From: Ivelin Ivanov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 9:52 PM
Subject: Re: Dynamic SelectOnes in XMLForms
This feature has been requested
similar.
I will not be able to work on this immediately.
Would you be interested to contribute the patch ?
Best,
Ivelin
- Original Message -
From: u13209
To: [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 2:04 AM
Subject: Dynamic SelectOnes in XMLForms
Hello everybody and Hello
Andrew C. Oliver wrote:
I've taken my first crack at this and its undergoing review before I
post it. I dislike both actions and the flowmap. More
specifically principally depending on Javascript.
Uh, thanks. I'm sure we'll be able to come up with a much better design
with such great
Nicola Ken Barozzi wrote:
Per-Olof Norén wrote:
Ivelin Ivanov wrote:
Nicola Ken Barozzi wrote:
IMNSHO, the flowmap should totally replace actions and deprecate them.
Ahem, I thought we decided *not* to deprecate them, as they make
sense as elements in the declarative sitemap.
For
I've taken my first crack at this and its undergoing review before I
post it. I dislike both actions and the flowmap. More
specifically principally depending on Javascript.
-Andy
Christian Haul wrote:
Nicola Ken Barozzi wrote:
Per-Olof Norén wrote:
Ivelin Ivanov wrote:
Nicola Ken
Nicola Ken Barozzi wrote:
Per-Olof Norén wrote:
Ivelin Ivanov wrote:
Nicola Ken Barozzi wrote:
IMNSHO, the flowmap should totally replace actions and deprecate them.
Ahem, I thought we decided *not* to deprecate them, as they make
sense as elements in the declarative sitemap.
For
Ivelin Ivanov wrote:
Andrew C. Oliver wrote:
The spirit of this group has been that every contributor's opinion
matters.
One of the reasons I got hooked and am spending so much time on the
list...
Don't mind me I'm just having a bad week. ;-)
On Sun, 16 Jun 2002, Ivelin Ivanov wrote:
Nicola Ken Barozzi wrote:
IMNSHO, the flowmap should totally replace actions and deprecate them.
Ahem, I thought we decided *not* to deprecate them, as they make sense
as elements in the declarative sitemap.
For web apps Actions should be
Ivelin Ivanov wrote:
Reinhard,
We are looking for someone to step up and show us how these two can work
together in a nice way.
Interested?
I am.
IMNSHO, the flowmap should totally replace actions and deprecate them.
I've looked at XMLForms and I must say it looks extremely
Daniel Fagerström wrote:
[skip lots of great stuff]
I strongly sugests that we should _not_ make general use of
continuations available in the flowmap language as there is no need for
it for what flowmaps are intended to do: describing multipage flow in
webapps.
Daniel,
thanks for your
to step up and show us how these two can work
together in a nice way.
Interested?
I am.
IMNSHO, the flowmap should totally replace actions and deprecate them.
I've looked at XMLForms and I must say it looks extremely unfriendly to
my eyes. The reason? massive use of actions, which hide
Stefano Mazzocchi wrote:
Ivelin Ivanov wrote:
Reinhard,
We are looking for someone to step up and show us how these two can work
together in a nice way.
Interested?
I am.
IMNSHO, the flowmap should totally replace actions and deprecate them.
I've looked at XMLForms and I must say
On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
Feel free to ask if you need further clarification about my integration
proposal.
What *I'm* most interested in is a statement you made a while ago on
this list about the difficulties students can have learning about
Diana Shannon wrote:
On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
Feel free to ask if you need further clarification about my integration
proposal.
What *I'm* most interested in is a statement you made a while ago on
this list about the difficulties students
On 6/13/02 4:57 AM, Diana Shannon [EMAIL PROTECTED] wrote:
On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
Feel free to ask if you need further clarification about my integration
proposal.
What *I'm* most interested in is a statement you made a while ago on
this
On 6/13/02 7:49 AM, Daniel Fagerström [EMAIL PROTECTED] wrote:
Diana Shannon wrote:
On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
Feel free to ask if you need further clarification about my integration
proposal.
What *I'm* most interested in is a statement
1 - 100 of 126 matches
Mail list logo
