Joern Nettingsmeier wrote:
hi michael!
Michael Wechner wrote:
Jörn Nettingsmeier wrote:
hi everyone!
a headsup to all the fearless testers of 1.4:
i have committed a major rework of the usecase flow handling. while
it improves many things, it also breaks cforms saving.
i committed it anyways because i'm off the net for a few days, and i
wanted to have the stuff out the door before bit-rot sets in.
if this is a major inconvenience to you, please complain loudly,
generally speaking I think it's a very bad idea to commit stuff which
doesn't work and the person who could actually be asked is "leaving
the room".
well, as you can see, i'm still on the planet, only my hacking time is
quite limited this week due to worldly chores :)
well, it didn't sound like from what you have written ;-)
Why not commit this stuff into the sandbox or make it available as a
patch on Bugzilla so that any committer interested into it can start
from there without having to break the trunk version?
well, generally i totally agree with you. but in this case, i feel
i've been sitting on this code for too long, and the breakage affects
only a small (if crucial)
well, there you go ... where do you want to draw the line?
I think there is no excuse except maybe if security issues need to be
fixed and something else breaks because of such a fix.
Cheers
Michi
part of rather arcane example doctype that a) has been broken again
and again in the past due to cocoon changes, and few people seemed to
notice or care about and b) is not actually useful in itself and very
hard to customize, because all the really hard-to-get-right flow stuff
used to be a compile-time thing.
i feel the improvements in the usecase framework outweigh this minor
breakage, and it was to move that code out the door and hear other
people's opinions about it. before committing, i had asked a few times
if people were relying on the current cforms implementation, and
nobody spoke up.
frankly, i did not try very hard to fix the bug, because i think that
all this complicated document handling stuff should not be done in the
controller anyway, but in the model (i.e. not in flowscript, but in
the java usecase object). i need to dig into that some more, and find
out why it used to be done this way, but ultimately, my dream scenario
would be as follows:
* a cforms module that implements generic cforms support, is easily
extendable, provides run-time deployment and testing and has sane
exception handling and error messages with line numbers in it
* a small cforms-example module (or maybe we should call it
"contacts") that takes the place of the current cforms demo
* the document handling in the flow is moved into the usecase object,
as with all other document usecases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
