Joerg,
> BTW, this would be a good use case for
> @importance/@impact in status.xml. Was there any action on this after the
> discussion about it?
Propose a vote, There was not any action after that :-)
Joerg Heinicke wrote:
Reinhard PÃtz apache.org> writes:
Please don't forget to mention it our step in the documents.
You mean adding a "removed since 2.1.5" to the wiki docu?
And IIRC there is official documentation available too. I think of a
warning box at the top.
I would prefer a real cl
Reinhard PÃtz apache.org> writes:
> >> Please don't forget to mention it our step in the documents.
> >
> > You mean adding a "removed since 2.1.5" to the wiki docu?
>
> And IIRC there is official documentation available too. I think of a
> warning box at the top.
I would prefer a real clean u
Torsten Curdt wrote:
I asked over a cocoon-user. Up til now 100% of them are saying
remove it *now*. (about 17 users responded) It was clearly stated
the vast amount of options lead more to confusion than they are
helpful. ...as we already know :)
If noone objects I'll remove both blocks eithe
I asked over a cocoon-user. Up til now 100% of them are saying
remove it *now*. (about 17 users responded) It was clearly stated
the vast amount of options lead more to confusion than they are
helpful. ...as we already know :)
If noone objects I'll remove both blocks either tonight or tomorrow.
Torsten Curdt wrote:
I asked over a cocoon-user. Up til now 100% of them are saying
remove it *now*. (about 17 users responded) It was clearly stated
the vast amount of options lead more to confusion than they are
helpful. ...as we already know :)
If noone objects I'll remove both blocks eithe
I asked over a cocoon-user. Up til now 100% of them are saying remove
it *now*. (about 17 users responded) It was clearly stated the vast
amount of options lead more to confusion than they are helpful. ...as
we already know :)
If noone objects I'll remove both blocks either tonight or tomorrow.
I asked over a cocoon-user. Up til now 100% of them are
saying remove it *now*. (about 17 users responded) It was
clearly stated the vast amount of options lead more to
confusion than they are helpful. ...as we already know :)
If noone objects I'll remove both blocks either tonight or tomorrow.
Carsten Ziegeler wrote:
Torsten Curdt wrote:
I asked over a cocoon-user. Up til now 100% of them are
saying remove it *now*. (about 17 users responded) It was
clearly stated the vast amount of options lead more to
confusion than they are helpful. ...as we already know :)
If noone objects I'
On 12.03.2004 11:19, Torsten Curdt wrote:
I asked over a cocoon-user.
Thanks for that.
Up til now 100% of
them are saying remove it *now*. (about 17
users responded) It was clearly stated the
vast amount of options lead more to confusion
than they are helpful. ...as we already know :)
I did not e
Torsten Curdt wrote:
>
> I asked over a cocoon-user. Up til now 100% of them are
> saying remove it *now*. (about 17 users responded) It was
> clearly stated the vast amount of options lead more to
> confusion than they are helpful. ...as we already know :)
>
> If noone objects I'll remove bot
xmlform has already been deprecated for quite a while now. I think
it is safe to remove it.
It's only half a year:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107662678916017&w=4.
I would deprecate jxforms block now and remove both for 2.2 (which is
infact just a non-update to real block
On 10.03.2004 13:35, Torsten Curdt wrote:
xmlform has already been deprecated for quite a while now. I think it
is safe to remove it.
It's only half a year:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107662678916017&w=4.
I would deprecate jxforms block now and remove both for 2.2 (which i
Joerg Heinicke wrote:
On 10.03.2004 12:46, Unico Hommes wrote:
BTW, what about xmlform and jxforms. Are they still necessary?!
Perhaps its time for some clean up.
Sounds like a good idea. But I guess we have to deprecate
them first like we do with the former-woody block now.
xmlform has already
On 10.03.2004 12:46, Unico Hommes wrote:
BTW, what about xmlform and jxforms. Are they still necessary?!
Perhaps its time for some clean up.
Sounds like a good idea. But I guess we have to deprecate
them first like we do with the former-woody block now.
xmlform has already been deprecated for quit
Torsten Curdt wrote:
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and ge
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
> Bertrand Delacretaz wrote:
>
> > Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
> >
> >> Since we are currently in the middle of cleaning
> >> up and focussing on *the* one form framework I
> >> like to propose and get
I am glad we finally have something
which is supported by the community!
Thanks, guys
We thank *you*, Torsen.
It's great to have code contributed, but the hardest thing for a
developer is to remove his/her own contribution in such a simple and
painless way.
This is the greatest achievement th
Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone is using it so we won
Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept
Done
+1, with thanks for your work on it!
Ditto. I remember your presentations on forms at the first GT. So many
options we had at
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept
Done
+1, with thanks for your work on it!
Ditto. I remember your presentations on forms at the first GT. So many
options we had at that time ;-)
I am glad w
On 09.03.2004 16:05, Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone
Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone is using it so we won
Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone is using it so we won
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept
+1, with thanks for your work on it!
Ditto. I remember yo
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept
+1, with thanks for your work on it!
-Bertrand
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone is using it so we won't
need a grace period
28 matches
Mail list logo
