You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Joern Nettingsmeier <ne...@folkwang-hochschule.de> on 2006/11/01 02:18:10 UTC
Re: usecase handler update breaks cforms saving...
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 :)
> 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) 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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: usecase handler update breaks cforms saving...
Posted by Michael Wechner <mi...@wyona.com>.
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: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: usecase handler update breaks cforms saving...
Posted by Michael Wechner <mi...@wyona.com>.
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: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org