You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.org> on 2003/07/31 04:03:20 UTC
Creator API
It took me quite some time to figure out that the API of the Creator has
been changed, which means that all publications which
don't have multilingual enabled won't work anymore with regard to
content creation.
I would like to suggest that we put in back the methods without language
and use them as fallback when
the language is "null", because I don't think one can expect that every
publication needs to be multilingual.
As an example you can take the "forum" or the new "Lenya's Blog"
publication.
Thanks
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
>> matter of perspective really. i bet if we removed half the
>> "genericity" in the code that does no one any good the system would
>> suddenly be stable.
>
>
> I don't believe that is the reason why the info area has problems with
> stability.
me neither, but there are lots of other areas of the code that suffer
from trying to be all things to all people.
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Gregor J. Rothfuss wrote:
>>> these workarounds pile up,
>>
>>
>> this is no workaround at all. It's making Lenya more generic.
>
>
> matter of perspective really. i bet if we removed half the "genericity"
> in the code that does no one any good the system would suddenly be stable.
I don't believe that is the reason why the info area has problems with
stability.
Thanks
Michael
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
>> these workarounds pile up,
>
> this is no workaround at all. It's making Lenya more generic.
matter of perspective really. i bet if we removed half the "genericity"
in the code that does no one any good the system would suddenly be stable.
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Gregor J. Rothfuss wrote:
>> if one is building a publication from scratch or is using an existing
>> Lenya publication, then this would be fine. But if one already has a
>> Cocoon based website we cannot expect them to change all their files
>> into *_language.xml !
>
>
> why not? it is a very simple job that can be done with a shell script.
and what about dependencies? A shell script won't solve these!
>
>> I don't see it as a problem to write such a fallback. One just needs
>> to ask if language is null, and then call the language free methods.
>
>
> these workarounds pile up,
this is no workaround at all. It's making Lenya more generic.
Thanks
Michael
and lead to the lava flow pattern one can so
> readily observe in lenya.
>
> http://magnonel.guild.net/~schwern/talks/Refactoring/slides/slide004.html
>
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
> if one is building a publication from scratch or is using an existing
> Lenya publication, then this would be fine. But if one already has a
> Cocoon based website we cannot expect them to change all their files
> into *_language.xml !
why not? it is a very simple job that can be done with a shell script.
> I don't see it as a problem to write such a fallback. One just needs to
> ask if language is null, and then call the language free methods.
these workarounds pile up, and lead to the lava flow pattern one can so
readily observe in lenya.
http://magnonel.guild.net/~schwern/talks/Refactoring/slides/slide004.html
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Christian Egli wrote:
> BTW, we should probably also have a strategy on where to go with the
> creator. Currently there is the creator ant task which uses the
> DefaultCreator internally, then there are the two actions
> DefaultCreatorAction (which also uses the DefaultCreator internally)
> and the ParentChildCreatorAction. The DefaultCreator is essentially a
> fork of the ParentChildCreatorAction which has some of functionality
> factored out to the DefaultCreator and knows how to deal with the
> (new) SiteTree. The (old) ParentChildCreatorAction was left for
> backwards-compatibility with old publications.
i think the defaultcreator action is no longer needed (superceded by the
ant task)
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Christian Egli <ch...@wyona.com>.
Michael Wechner <mi...@wyona.org> writes:
> > I think the creator currently has a simple bug in it where it creates
> > a file named foo_.xml when the language is null. I propose to add a
> > simple change to the DefaultCreator create method along the lines of
> > Michis proposal which will simply not add a language suffix to the
> > created file if the language is null.
>
> +1
You might have seen my checkin. Implemented as proposed.
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Christian Egli wrote:
> Michael Wechner <mi...@wyona.org> writes:
>
>
>>Gregor J. Rothfuss wrote:
>>
>>>Michael Wechner wrote:
>>>
>>>
>>>>It took me quite some time to figure out that the API of the
>>>>Creator has been changed, which means that all publications which
>>>>don't have multilingual enabled won't work anymore with regard to
>>>>content creation.
>
>
> I thought the old publications use the ParentChildCreatorAction and
> aren't affected by the multilingual code which is AFAIK only used in
> the DefaultCreator.
this has nothing to do with the Action. Both actions are using the same
creators.
>
>
>>>>I would like to suggest that we put in back the methods without
>>>>language and use them as fallback when the language is "null",
>>>>because I don't think one can expect that every publication needs
>>>>to be multilingual.
>
>
>>>the other, better possibility being to have multilingualism
>>>enabled with one language. i'd rather not create yet more special
>>>cases, especially in an area that is as messy as the creators.
>>
>>if one is building a publication from scratch or is using an
>>existing Lenya publication, then this would be fine. But if one
>>already has a Cocoon based website we cannot expect them to change
>>all their files into *_language.xml !
>>
>>I don't see it as a problem to write such a fallback. One just needs
>>to ask if language is null, and then call the language free methods.
>
>
> I think the creator currently has a simple bug in it where it creates
> a file named foo_.xml when the language is null. I propose to add a
> simple change to the DefaultCreator create method along the lines of
> Michis proposal which will simply not add a language suffix to the
> created file if the language is null.
+1
>
> BTW, we should probably also have a strategy on where to go with the
> creator. Currently there is the creator ant task which uses the
> DefaultCreator internally, then there are the two actions
> DefaultCreatorAction (which also uses the DefaultCreator internally)
> and the ParentChildCreatorAction. The DefaultCreator is essentially a
> fork of the ParentChildCreatorAction which has some of functionality
> factored out to the DefaultCreator and knows how to deal with the
> (new) SiteTree. The (old) ParentChildCreatorAction was left for
> backwards-compatibility with old publications.
I think the goal is to get rid of the actions and only use the ant
tasks, but certain sample publications are still using the actions.
I will remove over time (any help appreciated).
I think it would help if we deprecate the documentation on creators
based on actions and at the same time document how one can implement
creators by using ant task
Thanks
Michael
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Christian Egli <ch...@wyona.com>.
Michael Wechner <mi...@wyona.org> writes:
> Gregor J. Rothfuss wrote:
> > Michael Wechner wrote:
> >
> >> It took me quite some time to figure out that the API of the
> >> Creator has been changed, which means that all publications which
> >> don't have multilingual enabled won't work anymore with regard to
> >> content creation.
I thought the old publications use the ParentChildCreatorAction and
aren't affected by the multilingual code which is AFAIK only used in
the DefaultCreator.
> >> I would like to suggest that we put in back the methods without
> >> language and use them as fallback when the language is "null",
> >> because I don't think one can expect that every publication needs
> >> to be multilingual.
> > the other, better possibility being to have multilingualism
> > enabled with one language. i'd rather not create yet more special
> > cases, especially in an area that is as messy as the creators.
>
> if one is building a publication from scratch or is using an
> existing Lenya publication, then this would be fine. But if one
> already has a Cocoon based website we cannot expect them to change
> all their files into *_language.xml !
>
> I don't see it as a problem to write such a fallback. One just needs
> to ask if language is null, and then call the language free methods.
I think the creator currently has a simple bug in it where it creates
a file named foo_.xml when the language is null. I propose to add a
simple change to the DefaultCreator create method along the lines of
Michis proposal which will simply not add a language suffix to the
created file if the language is null.
BTW, we should probably also have a strategy on where to go with the
creator. Currently there is the creator ant task which uses the
DefaultCreator internally, then there are the two actions
DefaultCreatorAction (which also uses the DefaultCreator internally)
and the ParentChildCreatorAction. The DefaultCreator is essentially a
fork of the ParentChildCreatorAction which has some of functionality
factored out to the DefaultCreator and knows how to deal with the
(new) SiteTree. The (old) ParentChildCreatorAction was left for
backwards-compatibility with old publications.
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> It took me quite some time to figure out that the API of the Creator
>> has been changed, which means that all publications which
>> don't have multilingual enabled won't work anymore with regard to
>> content creation.
>>
>> I would like to suggest that we put in back the methods without
>> language and use them as fallback when
>> the language is "null", because I don't think one can expect that
>> every publication needs to be multilingual.
>
>
> the other, better possibility being to have multilingualism enabled with
> one language. i'd rather not create yet more special cases, especially
> in an area that is as messy as the creators.
if one is building a publication from scratch or is using an existing
Lenya publication, then this would be fine. But if one already has a
Cocoon based website we cannot expect them to change all their files
into *_language.xml !
I don't see it as a problem to write such a fallback. One just needs to
ask if language is null, and then call the language free methods.
Thanks
Michael
>
> -gregor
>
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>> well, instead of changing the parameter object interface, one could
>> add new parameters via
>> methods, e.g.
>>
>> ParameterObject.setLanguage()
>>
>> which then could be retrieved via
>>
>> ParameterObject.getLanguage()
>>
>> or is there another pitfall?
>
>
> What exactly do you mean by "add new parameters via methods"?
>
> If that means adding new methods for new parameters,
yes
> then you change the parameter object's interface,
> which means changing the API ...
right, but it only breaks it when the methods are declared as abstract,
or am I totally confused here
Thanks
Michael
>
> I'm afraid that there is no silver bullet for this
> problem ...
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
> well, instead of changing the parameter object interface, one could add
> new parameters via
> methods, e.g.
>
> ParameterObject.setLanguage()
>
> which then could be retrieved via
>
> ParameterObject.getLanguage()
>
> or is there another pitfall?
What exactly do you mean by "add new parameters via methods"?
If that means adding new methods for new parameters,
then you change the parameter object's interface,
which means changing the API ...
I'm afraid that there is no silver bullet for this
problem ...
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>>>> Anyway, what about introducing a "Parameters" object, where one can
>>>> append the various parameters such as language, childid, parentid,
>>>> etc.
>>>> This way we don't have to change the API all the time when a new
>>>> parameter appears, but can add another method to the "Parameters"
>>>> object, similar to a request object.
>>>
>>>
>>> I can't agree with this. Such a design can be used if the
>>> implementation
>>> requires key-value parameters (like Cocoon actions or Lenya tasks).
>>
>>
>> Well, I am not talking about the key-value parameters. Such a
>> parameters attribute is already present, which is passing session
>> and request parameters along. I am talking about passing parameters
>> as a request (plz see below)
>
>
> Sorry, I got you wrong here. I thought of something like the Avalon
> Parameters, but you obviously mean the "introduce parameter object"
> refactoring
> (http://www.refactoring.com/catalog/introduceParameterObject.html)
>
> This is certainly a an appropriate solution to simplify the method
> signature. But it doesn't really solve the changing API problem
> (instead of changing the Creator interface you still have to change
> the parameter object interface).
well, instead of changing the parameter object interface, one could add
new parameters via
methods, e.g.
ParameterObject.setLanguage()
which then could be retrieved via
ParameterObject.getLanguage()
or is there another pitfall?
Thanks
Michael
>
>
>
>> I shouldn't have used the word parameters ;-)
>
>
> It's just the difference between singular and plural - one letter,
> but a very different association :)
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
>>> Anyway, what about introducing a "Parameters" object, where one can
>>> append the various parameters such as language, childid, parentid, etc.
>>> This way we don't have to change the API all the time when a new
>>> parameter appears, but can add another method to the "Parameters"
>>> object, similar to a request object.
>>
>> I can't agree with this. Such a design can be used if the implementation
>> requires key-value parameters (like Cocoon actions or Lenya tasks).
>
> Well, I am not talking about the key-value parameters. Such a parameters
> attribute is already present, which is passing session and request
> parameters along. I am talking about passing parameters as a request
> (plz see below)
Sorry, I got you wrong here. I thought of something like the Avalon
Parameters, but you obviously mean the "introduce parameter object"
refactoring
(http://www.refactoring.com/catalog/introduceParameterObject.html)
This is certainly a an appropriate solution to simplify the method
signature. But it doesn't really solve the changing API problem
(instead of changing the Creator interface you still have to change
the parameter object interface).
> I shouldn't have used the word parameters ;-)
It's just the difference between singular and plural - one letter,
but a very different association :)
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>>> Michael, I understand your concerns (also from the follow-up mails), but
>>> in this case I would suggest to defer the generalization until the
>>> creator is well-understood and stable. Sure, it makes it harder to
>>> gereralize a component later on, but at the moment I really see the need
>>> for consolidation and stability and the danger of featuritis.
>>
>>
>> it's not featuritis, it's about having a good API, which doesn't break
>> everytime in case one takes it one step further.
>
>
> OK, but "not breaking" is not the only requirement for a good API.
agreed
>
>> Anyway, what about introducing a "Parameters" object, where one can
>> append the various parameters such as language, childid, parentid, etc.
>> This way we don't have to change the API all the time when a new
>> parameter appears, but can add another method to the "Parameters"
>> object, similar to a request object.
>
>
> I can't agree with this. Such a design can be used if the implementation
> requires key-value parameters (like Cocoon actions or Lenya tasks).
Well, I am not talking about the key-value parameters. Such a parameters
attribute is already present, which is passing session and request
parameters along. I am talking about passing parameters as a request
(plz see below)
> In the case of the Creator, I would rather suggest the following
> strategy:
>
> - write tasks that implement the single operations that are executed
> during Document creation
> - call these tasks from the Ant target or a Creator task
> - for complex operations, use delegation for reuse instead of
> inheritance (i.e., write another class that does not extend the
> original creator but calls it if it needs its functionality)
yes, I will refactor the blog creator as an ant task
>
> The semantics of inheritance can easily be violated when a "parameters
> object" is used. And first of all, it does not define a contract.
The contract would be defined by the methods rather than the attributes,
e.g. CreatorRequest.getLanguage() CreatorRequest.getDocId(), etc.
I shouldn't have used the word parameters ;-)
Thanks
Michael
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> Anyway, what about introducing a "Parameters" object, where one can
>> append the various parameters such as language, childid, parentid, etc.
>> This way we don't have to change the API all the time when a new
>> parameter appears, but can add another method to the "Parameters"
>> object, similar to a request object.
-1
following on that argument, all APIs could be reduced to get(), put()
with an opaque object that contains all the necessary data
> I can't agree with this. Such a design can be used if the implementation
> requires key-value parameters (like Cocoon actions or Lenya tasks).
> In the case of the Creator, I would rather suggest the following
> strategy:
>
> - write tasks that implement the single operations that are executed
> during Document creation
> - call these tasks from the Ant target or a Creator task
> - for complex operations, use delegation for reuse instead of
> inheritance (i.e., write another class that does not extend the
> original creator but calls it if it needs its functionality)
>
> The semantics of inheritance can easily be violated when a "parameters
> object" is used. And first of all, it does not define a contract.
+1
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
>> Michael, I understand your concerns (also from the follow-up mails), but
>> in this case I would suggest to defer the generalization until the
>> creator is well-understood and stable. Sure, it makes it harder to
>> gereralize a component later on, but at the moment I really see the need
>> for consolidation and stability and the danger of featuritis.
>
> it's not featuritis, it's about having a good API, which doesn't break
> everytime in case one takes it one step further.
OK, but "not breaking" is not the only requirement for a good API.
> Anyway, what about introducing a "Parameters" object, where one can
> append the various parameters such as language, childid, parentid, etc.
> This way we don't have to change the API all the time when a new
> parameter appears, but can add another method to the "Parameters"
> object, similar to a request object.
I can't agree with this. Such a design can be used if the implementation
requires key-value parameters (like Cocoon actions or Lenya tasks).
In the case of the Creator, I would rather suggest the following
strategy:
- write tasks that implement the single operations that are executed
during Document creation
- call these tasks from the Ant target or a Creator task
- for complex operations, use delegation for reuse instead of
inheritance (i.e., write another class that does not extend the
original creator but calls it if it needs its functionality)
The semantics of inheritance can easily be violated when a "parameters
object" is used. And first of all, it does not define a contract.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Michael Wechner <mi...@wyona.org>.
Andreas Hartmann wrote:
> Gregor J. Rothfuss wrote:
>
>>> I would like to suggest that we put in back the methods without
>>> language and use them as fallback when
>>> the language is "null", because I don't think one can expect that
>>> every publication needs to be multilingual.
>>
>>
>>
>> the other, better possibility being to have multilingualism enabled
>> with one language. i'd rather not create yet more special cases,
>> especially in an area that is as messy as the creators.
>
>
> Michael, I understand your concerns (also from the follow-up mails), but
> in this case I would suggest to defer the generalization until the
> creator is well-understood and stable. Sure, it makes it harder to
> gereralize a component later on, but at the moment I really see the need
> for consolidation and stability and the danger of featuritis.
it's not featuritis, it's about having a good API, which doesn't break
everytime in case one takes it one step further.
Anyway, what about introducing a "Parameters" object, where one can
append the various parameters such as language, childid, parentid, etc.
This way we don't have to change the API all the time when a new
parameter appears, but can add another method to the "Parameters"
object, similar to a request object.
Makes sense?
Thanks
Michael
>
> I hope the general disagreement on flexibility vs. easy manageability
> won't cause any harm to the project. At the moment, I personally tend to
> support the manageability side.
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
--
Michael Wechner
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
>> I would like to suggest that we put in back the methods without
>> language and use them as fallback when
>> the language is "null", because I don't think one can expect that
>> every publication needs to be multilingual.
>
>
> the other, better possibility being to have multilingualism enabled with
> one language. i'd rather not create yet more special cases, especially
> in an area that is as messy as the creators.
Michael, I understand your concerns (also from the follow-up mails), but
in this case I would suggest to defer the generalization until the
creator is well-understood and stable. Sure, it makes it harder to
gereralize a component later on, but at the moment I really see the need
for consolidation and stability and the danger of featuritis.
I hope the general disagreement on flexibility vs. easy manageability
won't cause any harm to the project. At the moment, I personally tend to
support the manageability side.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Creator API
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> It took me quite some time to figure out that the API of the Creator has
> been changed, which means that all publications which
> don't have multilingual enabled won't work anymore with regard to
> content creation.
>
> I would like to suggest that we put in back the methods without language
> and use them as fallback when
> the language is "null", because I don't think one can expect that every
> publication needs to be multilingual.
the other, better possibility being to have multilingualism enabled with
one language. i'd rather not create yet more special cases, especially
in an area that is as messy as the creators.
-gregor
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org