You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jörn Nettingsmeier <po...@uni-duisburg.de> on 2006/06/03 19:43:37 UTC
LenyaMetaDataGenerator and java newbie questions..
hi thorsten, hi everyone!
i'm extending the LenyaMetaDataGenerator to provide clean xml output
that can be easily handled in xsl stylesheets.
i started by copying and modifying it, and now i want to make it a clean
subclass, because i only need to change one method (private void
parseMetaData(String type)).
the problem is that many methods are declared private... are there
objections against lifting the restrictions to "protected"?
and, since i would like to submit it for inclusion once it's been
cleaned up, what are the preferred coding standards wrt. whitespace and
code formatting in lenya?
best,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: LenyaMetaDataGenerator and java newbie questions..
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 05-06-2006 a las 11:59 +0200, Jörn Nettingsmeier escribió:
> On a sad and lonely bank holiday, Thorsten Scherler made my day by writing:
> > El sáb, 03-06-2006 a las 19:43 +0200, Jörn Nettingsmeier escribió:
> >> hi thorsten, hi everyone!
> >>
> >>
> >> i'm extending the LenyaMetaDataGenerator to provide clean xml output
> >> that can be easily handled in xsl stylesheets.
> >> i started by copying and modifying it, and now i want to make it a clean
> >> subclass, because i only need to change one method (private void
> >> parseMetaData(String type)).
> >>
> >> the problem is that many methods are declared private... are there
> >> objections against lifting the restrictions to "protected"?
> >>
> >
> > yes.
>
> can you be more specific?
Sorry. Yes we can lift the private restrictions where possible.
> what am i supposed to do instead? modify the original generator? or wrap
> it? if so, why? (note the "java *newbie*" in the subject :-D)
No, sorry just replace private with protected like you did in your
patch.
>
> >> and, since i would like to submit it for inclusion once it's been
> >> cleaned up, what are the preferred coding standards wrt. whitespace and
> >> code formatting in lenya?
> >>
> >
> > http://lenya.apache.org/1_2_x/misc/coding-guidelines.html
>
> thanks. ummm, i think i used tabs quite a bit... i'll rework the patch
> later today.
:)
Thanks (and please attach it to the issue tracker).
salu2
> best,
>
> jörn
>
>
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: LenyaMetaDataGenerator and java newbie questions..
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
On a sad and lonely bank holiday, Thorsten Scherler made my day by writing:
> El sáb, 03-06-2006 a las 19:43 +0200, Jörn Nettingsmeier escribió:
>> hi thorsten, hi everyone!
>>
>>
>> i'm extending the LenyaMetaDataGenerator to provide clean xml output
>> that can be easily handled in xsl stylesheets.
>> i started by copying and modifying it, and now i want to make it a clean
>> subclass, because i only need to change one method (private void
>> parseMetaData(String type)).
>>
>> the problem is that many methods are declared private... are there
>> objections against lifting the restrictions to "protected"?
>>
>
> yes.
can you be more specific?
what am i supposed to do instead? modify the original generator? or wrap
it? if so, why? (note the "java *newbie*" in the subject :-D)
>> and, since i would like to submit it for inclusion once it's been
>> cleaned up, what are the preferred coding standards wrt. whitespace and
>> code formatting in lenya?
>>
>
> http://lenya.apache.org/1_2_x/misc/coding-guidelines.html
thanks. ummm, i think i used tabs quite a bit... i'll rework the patch
later today.
best,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: LenyaMetaDataGenerator and java newbie questions..
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 03-06-2006 a las 19:43 +0200, Jörn Nettingsmeier escribió:
> hi thorsten, hi everyone!
>
>
> i'm extending the LenyaMetaDataGenerator to provide clean xml output
> that can be easily handled in xsl stylesheets.
> i started by copying and modifying it, and now i want to make it a clean
> subclass, because i only need to change one method (private void
> parseMetaData(String type)).
>
> the problem is that many methods are declared private... are there
> objections against lifting the restrictions to "protected"?
>
yes.
> and, since i would like to submit it for inclusion once it's been
> cleaned up, what are the preferred coding standards wrt. whitespace and
> code formatting in lenya?
>
http://lenya.apache.org/1_2_x/misc/coding-guidelines.html
> best,
>
> jörn
>
HTH
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Thorsten Scherler <th...@wyona.com>.
El mié, 14-06-2006 a las 13:08 +0200, Joern Nettingsmeier escribió:
> Thorsten Scherler wrote:
> >> ok, i'll try to send a patch against thorsten's code. thorsten, is that
> >> fine with you?
> >
> > Please go ahead and remember there is no such thing like thorsten's or
> > andrea's or michi's or ...'s code. If it is in Lenya it is Apache Lenya
> > code.
>
> sure. but if someone has made a contribution, i assume s/he has special
> interest in the code and does maintenance and coordination.
One feels generally speaking more responsible for the code but one has
not a special veto nor leadership or obligations.
>
> i've seen the other extreme in other projects, a "fire and forget"
> attitude towards code commits, and that's generally not helpful, so i'd
> rather hear "oh, wait, that's the area i'm working on, mind if i review
> your patch first".
All PMC member should review patches and commits. I personally do not
have time ATM (less with the world cup) but I will try to take some of
your patches, apply, review and commit them.
Like said all PMC member and committer should do this.
You are right if I would work ATM on this component it is helping that
we coordinate our efforts. Thanks for all the time and feedback you
invest in Lenya.
We are very grateful for your contributions.
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Thorsten Scherler wrote:
>> ok, i'll try to send a patch against thorsten's code. thorsten, is that
>> fine with you?
>
> Please go ahead and remember there is no such thing like thorsten's or
> andrea's or michi's or ...'s code. If it is in Lenya it is Apache Lenya
> code.
sure. but if someone has made a contribution, i assume s/he has special
interest in the code and does maintenance and coordination.
i've seen the other extreme in other projects, a "fire and forget"
attitude towards code commits, and that's generally not helpful, so i'd
rather hear "oh, wait, that's the area i'm working on, mind if i review
your patch first".
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 12-06-2006 a las 10:58 +0200, Joern Nettingsmeier escribió:
> Andreas Hartmann wrote:
> > Jörn Nettingsmeier wrote:
> >> * does anyone have objections or suggestions regarding the
> >> implementation? (whitespace will be fixed)
> >
> > Some questions:
> >
> > - Some methods are rather long with inline comments. Would it make
> > sense to refactor them into smaller methods with Javadocs?
>
> sure. i'll try to do that. re javadoc: should implementation details be
> documented as javadoc? or only information that is relevant for the API?
>
> > - The REALLY_HACKISH_SEPARATOR stuff looks a bit strange - is this
> > necessary?
>
> of course not. it's there to warn people that it's a really hackish
> separator. ;)
>
> i was looking for a regex function to do the job, and all i could think
> of was the replaceAll/split combination, so i needed a string that's
> guaranteed not to show up in workflowVersion, which is hard, since the
> data format is a) buggy (missing record separator), b) not really
> documented anywhere and c) obviously meant to be extensible in the
> future (var:...).
>
> is there a char that could safely be used? or better yet, a way to split
> the string in one step? i'm not really familiar with the java api, much
> less the regex implementation.
>
> >> * in the light of another recent discussion about lenya namespaces, what
> >> do you think about creating a new namespace for the output of the
> >> metadata generator, so as not to abuse the page-envelope ns? a
> >> suggestion is attached below, please comment.
> >
> > Actually I don't think that we need a special meta data namespace.
> > The actual meta data should have their own namespaces (see my proposals
> > about configurable meta data), and the surrounding elements could
> > use a general Lenya namespace.
>
> fine with me. so we create a new flat namespace (no wrappers), right? if
> we get rid of the wrapper elements, does my suggestion come close to
> what you're thinking of?
>
> what "general" lenya namespace do you have in mind?
>
> >> * since we're not exactly in code freeze, does it make sense to maintain
> >> this generator as a subclass of thorsten's implementation, or should we
> >> rather merge the two? i would prefer the latter.
> >
> > If there are no negative implications, I'm in favor of a single class.
> > The less code there is to maintain, the better.
>
> ok, i'll try to send a patch against thorsten's code. thorsten, is that
> fine with you?
Hmm, please, the code in lenya is lenya code. I happen to have written
the starting code but that is based on other work of this community. In
Apache there is no code ownership.
Anyway I am always very fine if someone attaches patches to the issue
tracker. ;)
Please go ahead and remember there is no such thing like thorsten's or
andrea's or michi's or ...'s code. If it is in Lenya it is Apache Lenya
code.
salu2
>
> >> btw, i'd like to suggest that in the future we try to create a working
> >> relaxng (or xml schema) for any and all new namespaces that are being
> >> introduced, and only then start coding. there is no better way for
> >> normative documentation imho. it would also be nice to come up with
> >> validation schemas for the namespaces that are already in use....
> >
> > Sounds good - but I fear
> > that the schemas won't be maintained
> > if they are not applied automatically ...
>
> is it so hard to first discuss and change the grammar before changing
> the code? i don't think this would slow down development...
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> * does anyone have objections or suggestions regarding the
>> implementation? (whitespace will be fixed)
>
> Some questions:
>
> - Some methods are rather long with inline comments. Would it make
> sense to refactor them into smaller methods with Javadocs?
sure. i'll try to do that. re javadoc: should implementation details be
documented as javadoc? or only information that is relevant for the API?
> - The REALLY_HACKISH_SEPARATOR stuff looks a bit strange - is this
> necessary?
of course not. it's there to warn people that it's a really hackish
separator. ;)
i was looking for a regex function to do the job, and all i could think
of was the replaceAll/split combination, so i needed a string that's
guaranteed not to show up in workflowVersion, which is hard, since the
data format is a) buggy (missing record separator), b) not really
documented anywhere and c) obviously meant to be extensible in the
future (var:...).
is there a char that could safely be used? or better yet, a way to split
the string in one step? i'm not really familiar with the java api, much
less the regex implementation.
>> * in the light of another recent discussion about lenya namespaces, what
>> do you think about creating a new namespace for the output of the
>> metadata generator, so as not to abuse the page-envelope ns? a
>> suggestion is attached below, please comment.
>
> Actually I don't think that we need a special meta data namespace.
> The actual meta data should have their own namespaces (see my proposals
> about configurable meta data), and the surrounding elements could
> use a general Lenya namespace.
fine with me. so we create a new flat namespace (no wrappers), right? if
we get rid of the wrapper elements, does my suggestion come close to
what you're thinking of?
what "general" lenya namespace do you have in mind?
>> * since we're not exactly in code freeze, does it make sense to maintain
>> this generator as a subclass of thorsten's implementation, or should we
>> rather merge the two? i would prefer the latter.
>
> If there are no negative implications, I'm in favor of a single class.
> The less code there is to maintain, the better.
ok, i'll try to send a patch against thorsten's code. thorsten, is that
fine with you?
>> btw, i'd like to suggest that in the future we try to create a working
>> relaxng (or xml schema) for any and all new namespaces that are being
>> introduced, and only then start coding. there is no better way for
>> normative documentation imho. it would also be nice to come up with
>> validation schemas for the namespaces that are already in use....
>
> Sounds good - but I fear
> that the schemas won't be maintained
> if they are not applied automatically ...
is it so hard to first discuss and change the grammar before changing
the code? i don't think this would slow down development...
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Jörn Nettingsmeier wrote:
>> Jörn Nettingsmeier wrote:
>>> hi thorsten, hi everyone!
>>
>> ok, here's my first attempt.
>>
>> the first patch changes all private methods in LenyaMetaDataGenerator
>> to "protected".
>>
>> the second file is a new subclass, LenyaSaneMetaDataGenerator (NOI
>> thorsten ;), that attempts to parse the messy metadata into something
>> more xmlish, which can then be handled more gracefully with xslts.
>> if you want to try it, just drop it into
>> src/java/org/apache/lenya/cms/cocoon/generation.
>>
>> the third patch activates the new generator in the default sitemap.
>> after rebuilding, browse default/authoring/meta&docid=index&lang=en
>> and check out the output. for maximum enjoyment, it is advisable to
>> submit the current document, otherwise there will be no workflow
>> metadata to view.
>
> before i push this patch into bugzilla for inclusion, a few questions:
>
> * does anyone have objections or suggestions regarding the
> implementation? (whitespace will be fixed)
Some questions:
- Some methods are rather long with inline comments. Would it make
sense to refactor them into smaller methods with Javadocs?
- The REALLY_HACKISH_SEPARATOR stuff looks a bit strange - is this
necessary?
> * in the light of another recent discussion about lenya namespaces, what
> do you think about creating a new namespace for the output of the
> metadata generator, so as not to abuse the page-envelope ns? a
> suggestion is attached below, please comment.
Actually I don't think that we need a special meta data namespace.
The actual meta data should have their own namespaces (see my proposals
about configurable meta data), and the surrounding elements could
use a general Lenya namespace.
> * since we're not exactly in code freeze, does it make sense to maintain
> this generator as a subclass of thorsten's implementation, or should we
> rather merge the two? i would prefer the latter.
If there are no negative implications, I'm in favor of a single class.
The less code there is to maintain, the better.
> btw, i'd like to suggest that in the future we try to create a working
> relaxng (or xml schema) for any and all new namespaces that are being
> introduced, and only then start coding. there is no better way for
> normative documentation imho. it would also be nice to come up with
> validation schemas for the namespaces that are already in use....
Sounds good - but I fear
that the schemas won't be maintained
if they are not applied automatically ...
-- Andreas
>
>
> regards,
>
>
> jörn
>
>
>
> ------------------------------------------------------------------------
>
> <?xml version="1.0" encoding="utf-8"?>
> <!--
> Suggested grammar for a new Lenya metadata namespace, target milestone 1.4.0.
> Namespace URI: http://apache.org/cocoon/lenya/document-metadata/1.0
> The suggested namespace prefix is "lenya-meta:".
> -->
>
> <grammar
> xmlns="http://relaxng.org/ns/structure/1.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema-datatypes"
>
> <start>
>
>
> <element name="meta"
> ns="http://apache.org/cocoon/lenya/document-metadata/1.0"
> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
>
> <element name="internal">
>
> <element name="resourceType"><data type="string"/></element>
>
> <element name="contentType"><data type="string"/></element>
>
> <optional>
> <element name="workflowHistory">
>
> <oneOrMore>
> <element name="revision">
> <attribute name="index">
> <data type="integer"/>
> </attribute>
> <element name="event">
> <choice>
> <value>create</value>
> <value>edit</value>
> <value>submit</value>
> <value>reject</value>
> <value>publish</value>
> </choice>
> </element>
> <element name="state">
> <!--
> this is probably be redundant, since state can
> be inferred from the revision history. are there
> any reasons we should keep it?
> -->
> <choice>
> <value>authoring</value>
> <value>review</value>
> <value>live</value>
> </choice>
> </element>
> <element name="isLive">
> <data type="boolean"/>
> </element>
> <element name="user">
> <data type="string"/>
> </element>
> <element name="machine">
> <data type="string">
> <param name="pattern">((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3} (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])"</param>
> </data>
> </element>
> <element name="timestamp">
> <data type="dateTime"/>
> </element>
> </element>
> </oneOrMore>
>
> </element>
> </optional>
>
> </element>
>
> <element name="dc">
> <oneOrMore>
> <element>
> <nsName ns="http://purl.org/dc/elements/1.1/"/>
> <data type="string"/>
> </element>
> </oneOrMore>
> </element>
>
> <element name="custom">
> <oneOrMore>
> <element>
> <anyName>
> <except>
> <nsName ns="http://apache.org/cocoon/lenya/document-metadata/1.0"/>
> </except>
> </anyName>
> <data type="string"/>
> </element>
> </oneOrMore>
> </element>
> </element>
>
> </start>
>
> </grammar>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Private Meta data (was Re: new LenyaMetaDataGenerator and new
namespace?)
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Joern Nettingsmeier wrote:
>>> if we go with the input module approach only and ditch the generator, we
>>> need very good documentation which must be updated frequently. the
>>> generator just outputs all available fields, so it always represents the
>>> current range of possibilities without requiring updates...
>> Another approach would be templating.
>>
>> Use some specific elements / attributes:
>>
>> <p>Published by <workflow:lastUser event="publish"/> ... </p>
>>
>> and fill in values using a transformer:
>>
>> <map:transform type="workflow-template"/>
>>
>>
>> This way, you don't have to pass the parameters explicitely to the XSL.
>
> nice!
> this would provide a really intuitive, consistent interface for users. i
> don't know how to implement transformers, but i would like to see
> someone do it :-D i'll be your alpha tester :)
OK - if you're interested in this functionality, would you mind
filing a bug, maybe with a syntax proposal, so that the idea
doesn't get lost? Thanks a lot!
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Private Meta data (was Re: new LenyaMetaDataGenerator and new
namespace?)
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Joern Nettingsmeier wrote:
>> if we go with the input module approach only and ditch the generator, we
>> need very good documentation which must be updated frequently. the
>> generator just outputs all available fields, so it always represents the
>> current range of possibilities without requiring updates...
>
> Another approach would be templating.
>
> Use some specific elements / attributes:
>
> <p>Published by <workflow:lastUser event="publish"/> ... </p>
>
> and fill in values using a transformer:
>
> <map:transform type="workflow-template"/>
>
>
> This way, you don't have to pass the parameters explicitely to the XSL.
nice!
this would provide a really intuitive, consistent interface for users. i
don't know how to implement transformers, but i would like to see
someone do it :-D i'll be your alpha tester :)
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Private Meta data (was Re: new LenyaMetaDataGenerator and new
namespace?)
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier wrote:
> Thorsten Scherler wrote:
>
>> I totally agree that we need private meta data and would like to remove
>> the lenya:internal data block from the generator since it is causing
>> many confusions and this private data should not be exposed to xml.
>
> well, i'm using it in the main site aggregator.
> the advantage of a generator that spits out all the available metadata
> at once (as opposed to singe-value input module calls like andreas
> suggests) is that a) you see what's available at a glance and b) you
> avoid having to pass several parameters to your xsl transformer which is
> always kludgy, since both the sitemap and the stylesheet have to know
> about those parameters.
>
> i see the architectural benefits of andreas' approach, but it's not as
> easy to learn to use as the current all-in-one generator. and imho
> ease-of-use on the sitemap level is currently under-valued in lenya. the
> sitemaps are the primary api for most new users, and they need to be
> lean and mean.
>
> if we go with the input module approach only and ditch the generator, we
> need very good documentation which must be updated frequently. the
> generator just outputs all available fields, so it always represents the
> current range of possibilities without requiring updates...
Another approach would be templating.
Use some specific elements / attributes:
<p>Published by <workflow:lastUser event="publish"/> ... </p>
and fill in values using a transformer:
<map:transform type="workflow-template"/>
This way, you don't have to pass the parameters explicitely to the XSL.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Private Meta data (was Re: new LenyaMetaDataGenerator and new
namespace?)
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Thorsten Scherler wrote:
> I totally agree that we need private meta data and would like to remove
> the lenya:internal data block from the generator since it is causing
> many confusions and this private data should not be exposed to xml.
well, i'm using it in the main site aggregator.
the advantage of a generator that spits out all the available metadata
at once (as opposed to singe-value input module calls like andreas
suggests) is that a) you see what's available at a glance and b) you
avoid having to pass several parameters to your xsl transformer which is
always kludgy, since both the sitemap and the stylesheet have to know
about those parameters.
i see the architectural benefits of andreas' approach, but it's not as
easy to learn to use as the current all-in-one generator. and imho
ease-of-use on the sitemap level is currently under-valued in lenya. the
sitemaps are the primary api for most new users, and they need to be
lean and mean.
if we go with the input module approach only and ditch the generator, we
need very good documentation which must be updated frequently. the
generator just outputs all available fields, so it always represents the
current range of possibilities without requiring updates...
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Private Meta data (was Re: new LenyaMetaDataGenerator and new
namespace?)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 13-06-2006 a las 16:58 +0200, Andreas Hartmann escribió:
> Jörn Nettingsmeier wrote:
> > Andreas Hartmann wrote:
> >> Jörn Nettingsmeier wrote:
> >>> what i do care about is stopping people from ever again introducing
> >>> multi-dimensional, semantically overloaded metadata tables (!) with
> >>> built-in extensibility (!!) represented as single strings (!!!)
> >>> without so much as a passing regard for documenting this whole pile
> >>> of shit anywhere, and then having to use (shudder!) regexes to clean
> >>> up the mess.
> >>>
> >>> workflowVersion in its current state is an abomination unto $deity
> >>> and must die.
> >>> fast.
> >>> violently.
> >>
> >> Actually I don't really understand this concern. The workflowVersion
> >> meta data are accessed only by the workflow engine, they are strictly
> >> private and I see no need for applying any regular expressions on
> >> them. If you need workflow information, ask the workflow engine ...
> >
> >
...
> > my starting point to achieve this goal was the LenyaMetaDataGenerator,
> > which was written by a seasoned contributor to lenya, so i figured that
> > this was the most obvious and consistent way to get at the data i need.
>
> No, this would be the wrong way. Unfortunately the generator publishes
> the workflow meta data, which should be avoided. We could introduce
> private meta data, or maybe it would be better to introduce a whole
> new concept, e.g. internal document properties. But this would make
> the code more complex.
I totally agree that we need private meta data and would like to remove
the lenya:internal data block from the generator since it is causing
many confusions and this private data should not be exposed to xml.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier wrote:
>>>> Andreas Hartmann wrote:
>>>>> Jörn Nettingsmeier wrote:
>>>>>> Andreas Hartmann wrote:
>>>>>>> Jörn Nettingsmeier wrote: Actually I don't really
>>>>>>> understand this concern. The workflowVersion meta data
>>>>>>> are accessed only by the workflow engine, they are
>>>>>>> strictly private and I see no need for applying any
>>>>>>> regular expressions on them. If you need workflow
>>>>>>> information, ask the workflow engine ...
>>>>>>
>>>>>> take the case of a "last modified on...by..." footer.
>>>>>> that's probably the most basic cms feature than i could
>>>>>> think of. it is currently not possible with lenya.
>>>>>
>>>>> That should be provided by the WorkflowModule.
>>>>
>>>> you java, me cocoon pipeline. in my world, there is no such
>>>> information.
>>>
>>> The WorkflowModule is an input module, so it would be e.g.
>>>
>>> <map:transform ...> <map:parameter name="lastWfUser"
>>> value="{workflow:last-user:publish}"/> <map:parameter
>>> name="lastWfDate" value="{workflow:last-date:publish}"/>
>>> </map:transform>
>>
>> neat. probably lenya's best kept secret. i was not aware that this
>> module exists. let's use it somewhere in the default publication.
>
> Please don't get this wrong - the module exists, but it doesn't
> support these attributes yet.
/me creeps out from under his chair and does not feel stupid anymore :-D
> Would you like to make a proposal about the syntax, or even provide a
> patch?
not this week, i'm swamped with work as it is, and i've been bitching
on this list so much lately that there's already a pile of things to
follow-up on.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier wrote:
>>> Andreas Hartmann wrote:
>>>> Jörn Nettingsmeier wrote:
>>>>> Andreas Hartmann wrote:
>>>>>> Jörn Nettingsmeier wrote:
>>>>>> Actually I don't really understand this concern. The workflowVersion
>>>>>> meta data are accessed only by the workflow engine, they are strictly
>>>>>> private and I see no need for applying any regular expressions on
>>>>>> them. If you need workflow information, ask the workflow engine ...
>>>>>
>>>>> take the case of a "last modified on...by..." footer. that's
>>>>> probably the most basic cms feature than i could think of. it is
>>>>> currently not possible with lenya.
>>>>
>>>> That should be provided by the WorkflowModule.
>>>
>>> you java, me cocoon pipeline. in my world, there is no such information.
>>
>> The WorkflowModule is an input module, so it would be e.g.
>>
>> <map:transform ...>
>> <map:parameter name="lastWfUser"
>> value="{workflow:last-user:publish}"/>
>> <map:parameter name="lastWfDate"
>> value="{workflow:last-date:publish}"/>
>> </map:transform>
>
> neat. probably lenya's best kept secret. i was not aware that this
> module exists. let's use it somewhere in the default publication.
Please don't get this wrong - the module exists, but it doesn't support
these attributes yet. Would you like to make a proposal about the
syntax, or even provide a patch?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier wrote:
>>>> Andreas Hartmann wrote:
>>>>> Jörn Nettingsmeier wrote:
>>>>> Actually I don't really understand this concern. The workflowVersion
>>>>> meta data are accessed only by the workflow engine, they are strictly
>>>>> private and I see no need for applying any regular expressions on
>>>>> them. If you need workflow information, ask the workflow engine ...
>>>>
>>>> take the case of a "last modified on...by..." footer. that's
>>>> probably the most basic cms feature than i could think of. it is
>>>> currently not possible with lenya.
>>>
>>> That should be provided by the WorkflowModule.
>>
>> you java, me cocoon pipeline. in my world, there is no such information.
>
> The WorkflowModule is an input module, so it would be e.g.
>
> <map:transform ...>
> <map:parameter name="lastWfUser" value="{workflow:last-user:publish}"/>
> <map:parameter name="lastWfDate" value="{workflow:last-date:publish}"/>
> </map:transform>
neat. probably lenya's best kept secret. i was not aware that this
module exists. let's use it somewhere in the default publication.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier wrote:
>>>> Andreas Hartmann wrote:
>>>>> Jörn Nettingsmeier wrote:
>>>>> Actually I don't really understand this concern. The workflowVersion
>>>>> meta data are accessed only by the workflow engine, they are strictly
>>>>> private and I see no need for applying any regular expressions on
>>>>> them. If you need workflow information, ask the workflow engine ...
>>>>
>>>> take the case of a "last modified on...by..." footer. that's
>>>> probably the most basic cms feature than i could think of. it is
>>>> currently not possible with lenya.
>>>
>>> That should be provided by the WorkflowModule.
>>
>> you java, me cocoon pipeline. in my world, there is no such information.
>
> The WorkflowModule is an input module, so it would be e.g.
>
> <map:transform ...>
> <map:parameter name="lastWfUser" value="{workflow:last-user:publish}"/>
> <map:parameter name="lastWfDate" value="{workflow:last-date:publish}"/>
> </map:transform>
I added the attributes lastUser.<event> and lastDate.<event> to the
WorkflowModule, and added a footer to the default publication which
uses these attributes. The variable.<variable> attribute already
used the dot as separator, so I stuck to this convention.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier wrote:
>>> Andreas Hartmann wrote:
>>>> Jörn Nettingsmeier wrote:
>>>> Actually I don't really understand this concern. The workflowVersion
>>>> meta data are accessed only by the workflow engine, they are strictly
>>>> private and I see no need for applying any regular expressions on
>>>> them. If you need workflow information, ask the workflow engine ...
>>>
>>> take the case of a "last modified on...by..." footer. that's probably
>>> the most basic cms feature than i could think of. it is currently not
>>> possible with lenya.
>>
>> That should be provided by the WorkflowModule.
>
> you java, me cocoon pipeline. in my world, there is no such information.
The WorkflowModule is an input module, so it would be e.g.
<map:transform ...>
<map:parameter name="lastWfUser" value="{workflow:last-user:publish}"/>
<map:parameter name="lastWfDate" value="{workflow:last-date:publish}"/>
</map:transform>
[...]
>> No, this would be the wrong way. Unfortunately the generator publishes
>> the workflow meta data, which should be avoided. We could introduce
>> private meta data, or maybe it would be better to introduce a whole
>> new concept, e.g. internal document properties. But this would make
>> the code more complex.
>
> i see what you're aiming for. but as it is now, and from a user
> perspective, it would just be nice to get at all the metadata in a
> clean, xmlish way.
You can use the input module, or we could add a workflow generator
which produces a list of all versions etc.
> the problem with wrapping everything up to the nth degree is that i can
> only do things that the developers have thought of already. i come from
> the unix world, and i'm used to easily being able to do things ken
> thompson never dreamed of :)
>
> the api should not anticipate everything - just make all the data
> available in an easy way and let the users think of clever things to do
> with it.
> as the saying goes, "if [an interface] prevents you from doing stupid
> things, it also prevents you from doing clever things."
Hmmm, never heard of that :)
>>> of course i could gather the data from all over the place, but that
>>> would make things even more inconsistent. as it is now, every
>>> document has its own metadata. that's nice and should remain as it
>>> is. all i'm asking for is that this metadata is structured,
>>> documented and handled in a sane way.
>>>
>>> if, as you say, the workflowVersion data is private and encapsulated,
>>> that's even less of an excuse to have all that substring() mayhem in
>>> the getter functions (see
>>> java/org/apache/lenya/cms/workflow/DocumentWorkflowable.java#getVersions).
>>>
>>
>> Why is that bad? The DocumentWorkflowable is the single entry point
>> for workflow version persistence. It can use whatever format it likes.
>
> the first programming language i have learned is c, and i hence believe
> in the "beauty in depth" principle, as opposed to the java "if you hate
> it, wrap it up" approach. :-D
>
>>> basically all i want the metadata generator to do is spit out the
>>> contents of the metadata xml file. of course that file is
>>> implementation-dependant, so i can't just read it, but still the data
>>> should be all in one place internally.
>>
>> They should be provided by the respective component. In the case
>> of workflow, the meta data are just a simple way to persist
>> document-related information.
>
> take the point of view of a new user getting to know lenya. what's
> easier: a) reading the metadata file of a document and seeing all
> document properties at one glance and be able to do things with them, or
> b) wait for some lenya developer to write a boxes-and-arrows model that
> will convey the same information and then glean the data from some java
> api that will materialize any day now?
That's why we have to prevent users from taking approach (a).
The workflow meta data may not be visible.
> i'll give away the answer: it's a) :-D
> and a) will make you wish you had a way to use that information in
> pipelines, stylesheets and selectors.
I totally agree -> WorkflowModule, WorkflowVersionsGenerator.
> so we need a simple way to get it. the metadata generator does it. and
> it should do that in a way that closely resembles the original data
> structure, so that if i know its output, i can read the java code and go
> "aha" all the time, as opposed to cursing "why the fuck is there another
> abstraction layer between me and my productivity" :-D
I see your point, but I don't really share this opinion. I believe
in established principles like abstraction, encapsulation, and
design patterns.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier wrote:
>>> Actually I don't really understand this concern. The workflowVersion
>>> meta data are accessed only by the workflow engine, they are strictly
>>> private and I see no need for applying any regular expressions on
>>> them. If you need workflow information, ask the workflow engine ...
>>
>> take the case of a "last modified on...by..." footer. that's probably
>> the most basic cms feature than i could think of. it is currently not
>> possible with lenya.
>
> That should be provided by the WorkflowModule.
you java, me cocoon pipeline. in my world, there is no such information.
>> this information *must* absolutely be available on a cocoon level,
>> either as from an input module or a generator or both. talking about
>> writing custom java code for this every time i need it is just
>> ridiculous.
>
> Sure, it should come out of the box.
>
>
>> my starting point to achieve this goal was the LenyaMetaDataGenerator,
>> which was written by a seasoned contributor to lenya, so i figured
>> that this was the most obvious and consistent way to get at the data i
>> need.
>
> No, this would be the wrong way. Unfortunately the generator publishes
> the workflow meta data, which should be avoided. We could introduce
> private meta data, or maybe it would be better to introduce a whole
> new concept, e.g. internal document properties. But this would make
> the code more complex.
i see what you're aiming for. but as it is now, and from a user
perspective, it would just be nice to get at all the metadata in a
clean, xmlish way.
the problem with wrapping everything up to the nth degree is that i can
only do things that the developers have thought of already. i come from
the unix world, and i'm used to easily being able to do things ken
thompson never dreamed of :)
the api should not anticipate everything - just make all the data
available in an easy way and let the users think of clever things to do
with it.
as the saying goes, "if [an interface] prevents you from doing stupid
things, it also prevents you from doing clever things."
>> of course i could gather the data from all over the place, but that
>> would make things even more inconsistent. as it is now, every document
>> has its own metadata. that's nice and should remain as it is. all i'm
>> asking for is that this metadata is structured, documented and handled
>> in a sane way.
>>
>> if, as you say, the workflowVersion data is private and encapsulated,
>> that's even less of an excuse to have all that substring() mayhem in
>> the getter functions (see
>> java/org/apache/lenya/cms/workflow/DocumentWorkflowable.java#getVersions).
>>
>
> Why is that bad? The DocumentWorkflowable is the single entry point
> for workflow version persistence. It can use whatever format it likes.
the first programming language i have learned is c, and i hence believe
in the "beauty in depth" principle, as opposed to the java "if you hate
it, wrap it up" approach. :-D
>> basically all i want the metadata generator to do is spit out the
>> contents of the metadata xml file. of course that file is
>> implementation-dependant, so i can't just read it, but still the data
>> should be all in one place internally.
>
> They should be provided by the respective component. In the case
> of workflow, the meta data are just a simple way to persist
> document-related information.
take the point of view of a new user getting to know lenya. what's
easier: a) reading the metadata file of a document and seeing all
document properties at one glance and be able to do things with them, or
b) wait for some lenya developer to write a boxes-and-arrows model that
will convey the same information and then glean the data from some java
api that will materialize any day now?
i'll give away the answer: it's a) :-D
and a) will make you wish you had a way to use that information in
pipelines, stylesheets and selectors.
so we need a simple way to get it. the metadata generator does it. and
it should do that in a way that closely resembles the original data
structure, so that if i know its output, i can read the java code and go
"aha" all the time, as opposed to cursing "why the fuck is there another
abstraction layer between me and my productivity" :-D
regards,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier wrote:
>>> what i do care about is stopping people from ever again introducing
>>> multi-dimensional, semantically overloaded metadata tables (!) with
>>> built-in extensibility (!!) represented as single strings (!!!)
>>> without so much as a passing regard for documenting this whole pile
>>> of shit anywhere, and then having to use (shudder!) regexes to clean
>>> up the mess.
>>>
>>> workflowVersion in its current state is an abomination unto $deity
>>> and must die.
>>> fast.
>>> violently.
>>
>> Actually I don't really understand this concern. The workflowVersion
>> meta data are accessed only by the workflow engine, they are strictly
>> private and I see no need for applying any regular expressions on
>> them. If you need workflow information, ask the workflow engine ...
>
> take the case of a "last modified on...by..." footer. that's probably
> the most basic cms feature than i could think of. it is currently not
> possible with lenya.
That should be provided by the WorkflowModule.
> this information *must* absolutely be available on a cocoon level,
> either as from an input module or a generator or both. talking about
> writing custom java code for this every time i need it is just ridiculous.
Sure, it should come out of the box.
> my starting point to achieve this goal was the LenyaMetaDataGenerator,
> which was written by a seasoned contributor to lenya, so i figured that
> this was the most obvious and consistent way to get at the data i need.
No, this would be the wrong way. Unfortunately the generator publishes
the workflow meta data, which should be avoided. We could introduce
private meta data, or maybe it would be better to introduce a whole
new concept, e.g. internal document properties. But this would make
the code more complex.
> of course i could gather the data from all over the place, but that
> would make things even more inconsistent. as it is now, every document
> has its own metadata. that's nice and should remain as it is. all i'm
> asking for is that this metadata is structured, documented and handled
> in a sane way.
>
> if, as you say, the workflowVersion data is private and encapsulated,
> that's even less of an excuse to have all that substring() mayhem in the
> getter functions (see
> java/org/apache/lenya/cms/workflow/DocumentWorkflowable.java#getVersions).
Why is that bad? The DocumentWorkflowable is the single entry point
for workflow version persistence. It can use whatever format it likes.
> basically all i want the metadata generator to do is spit out the
> contents of the metadata xml file. of course that file is
> implementation-dependant, so i can't just read it, but still the data
> should be all in one place internally.
They should be provided by the respective component. In the case
of workflow, the meta data are just a simple way to persist
document-related information.
>> There's no point in specifying the workflow meta data, because they
>> might change, and every workflow engine might use its own meta data
>> format.
>
> there is no point in specifying things because they might change? by
> that reasoning, the entire w3.org website is obsolete by definition.
You're right, so please remove the first part of my last statement :)
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> what i do care about is stopping people from ever again introducing
>> multi-dimensional, semantically overloaded metadata tables (!) with
>> built-in extensibility (!!) represented as single strings (!!!)
>> without so much as a passing regard for documenting this whole pile of
>> shit anywhere, and then having to use (shudder!) regexes to clean up
>> the mess.
>>
>> workflowVersion in its current state is an abomination unto $deity and
>> must die.
>> fast.
>> violently.
>
> Actually I don't really understand this concern. The workflowVersion
> meta data are accessed only by the workflow engine, they are strictly
> private and I see no need for applying any regular expressions on
> them. If you need workflow information, ask the workflow engine ...
take the case of a "last modified on...by..." footer. that's probably
the most basic cms feature than i could think of. it is currently not
possible with lenya.
this information *must* absolutely be available on a cocoon level,
either as from an input module or a generator or both. talking about
writing custom java code for this every time i need it is just ridiculous.
my starting point to achieve this goal was the LenyaMetaDataGenerator,
which was written by a seasoned contributor to lenya, so i figured that
this was the most obvious and consistent way to get at the data i need.
of course i could gather the data from all over the place, but that
would make things even more inconsistent. as it is now, every document
has its own metadata. that's nice and should remain as it is. all i'm
asking for is that this metadata is structured, documented and handled
in a sane way.
if, as you say, the workflowVersion data is private and encapsulated,
that's even less of an excuse to have all that substring() mayhem in the
getter functions (see
java/org/apache/lenya/cms/workflow/DocumentWorkflowable.java#getVersions).
basically all i want the metadata generator to do is spit out the
contents of the metadata xml file. of course that file is
implementation-dependant, so i can't just read it, but still the data
should be all in one place internally.
> There's no point in specifying the workflow meta data, because they
> might change, and every workflow engine might use its own meta data
> format.
there is no point in specifying things because they might change? by
that reasoning, the entire w3.org website is obsolete by definition.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
[...]
>> Well, IMO Lenya should behave like a framework and define the
>> structure of the meta data, but not the actual content. It should
>> be possible to add components without modifying the core. What
>> if you want to use a custom Workflow component which doesn't use
>> version elements to store meta data, or something like that?
>
> just to clarify: basically all i wanted to say with the whole namespace
> shebang is this:
>
> let's first write the data specification.
>
> then implement the specification.
>
> (as opposed to hack in a bunch of variables as needed and call them
> metadata.)
>
> i don't care whether this is done with a relaxng grammar for the xml
> realm, or with a nice javadoc comment for the object realm, as long as
> it's done.
> i don't care about the details of this specification either.
> what i do care about is stopping people from ever again introducing
> multi-dimensional, semantically overloaded metadata tables (!) with
> built-in extensibility (!!) represented as single strings (!!!) without
> so much as a passing regard for documenting this whole pile of shit
> anywhere, and then having to use (shudder!) regexes to clean up the mess.
>
> workflowVersion in its current state is an abomination unto $deity and
> must die.
> fast.
> violently.
Actually I don't really understand this concern. The workflowVersion
meta data are accessed only by the workflow engine, they are strictly
private and I see no need for applying any regular expressions on
them. If you need workflow information, ask the workflow engine ...
There's no point in specifying the workflow meta data, because they
might change, and every workflow engine might use its own meta data
format.
IMO the real problem is that we can't distinguish between "private"
and "public" meta data yet.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Joern Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Hi Jörn,
>>>
>>> IMO the problem about this schema is that it is not generic,
>>> i.e. it is not possible to add custom meta data sets without
>>> changing the schema.
>>
>> that's a feature.
>
> Well, IMO Lenya should behave like a framework and define the
> structure of the meta data, but not the actual content. It should
> be possible to add components without modifying the core. What
> if you want to use a custom Workflow component which doesn't use
> version elements to store meta data, or something like that?
just to clarify: basically all i wanted to say with the whole namespace
shebang is this:
let's first write the data specification.
then implement the specification.
(as opposed to hack in a bunch of variables as needed and call them
metadata.)
i don't care whether this is done with a relaxng grammar for the xml
realm, or with a nice javadoc comment for the object realm, as long as
it's done.
i don't care about the details of this specification either.
what i do care about is stopping people from ever again introducing
multi-dimensional, semantically overloaded metadata tables (!) with
built-in extensibility (!!) represented as single strings (!!!) without
so much as a passing regard for documenting this whole pile of shit
anywhere, and then having to use (shudder!) regexes to clean up the mess.
workflowVersion in its current state is an abomination unto $deity and
must die.
fast.
violently.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Hi Jörn,
>>
>> IMO the problem about this schema is that it is not generic,
>> i.e. it is not possible to add custom meta data sets without
>> changing the schema.
>
> that's a feature.
Well, IMO Lenya should behave like a framework and define the
structure of the meta data, but not the actual content. It should
be possible to add components without modifying the core. What
if you want to use a custom Workflow component which doesn't use
version elements to store meta data, or something like that?
[...]
> SoC at its very best, and totally useless for both validation *and*
> documentation.
In the case of meta data, validation and documentation shouldn't
be applied to the XML format. The format is just a representation
of the internal meta data. The actual validation is done when
the meta data are entered via the API (MetaDataManager.setValue()
or something like that).
The internal meta data are not meant to be transmitted between
applications, for this purpose you would provide explicit interfaces.
These interfaces could make use of a special grammar.
Actually, I would like to introduce something like "private"
meta data, which can only be accessed by a certain component.
This would apply for instance to workflow meta data. They wouldn't
be exposed by the LenyaMetaDataGenerator etc.
> incidentally, it pretty much reflects the current state,
> except that it is hierarchic :-D
>
> my suggestion is extensible, but it requires an element hierarchy for
> that - as you said, that's not desirable for internal representation.
>
> so how about this:
>
> we define a grammar that can contain some fixed lenya-internal metadata
> items from a special namespace "lenya-meta:". these are validatated in a
> very thorough way, and must be represented 1:1 in the grammar, leading
> to a well-defined api and good documentation.
IMO the well-defined API and documentation should be handled by
declaring meta data sets. The declaration would serve as a configuration
for the meta data management component, which would be reponsible to
validate values.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Hi Jörn,
>
> IMO the problem about this schema is that it is not generic,
> i.e. it is not possible to add custom meta data sets without
> changing the schema.
that's a feature.
> Additionally, if you convert meta data
> to elements, you have to make assumptions, e.g. regarding the
> internal storage of workflow versions. This is a concern of
> the workflow engine, the meta data component may only read or
> write the meta data but not try to parse or understand them.
>
>
> I'd prefer something like this:
>
> <meta-data xmlns="http://apache.org/lenya/...">
>
> <elements namespace="...">
> <element name="foo">
> <value>hello</value>
> <value>world</value>
> </element>
> ...
> </elements>
>
> ...
>
> </meta-data>
>
>
> I understand that this is not as good as your suggestion when
> it comes to validation, but IMO we have to use a really extensible
> and generic format to render meta data as XML.
depends on what you want. i intended the grammar to be fixed and
non-extensible wrt core metadata, so that it really hurts to introduce
changes :)
moreover, the more detailed and less flexible a grammar is, the better
it is for documentation.
ultimately, the most flexible solution is
<define name="everythingandthekitchensink">
<element>
<nsName/>
<zeroOrMore>
<attribute>
<anyName/>
<optional>
<text/>
</optional>
</attribute>
</zeroOrMore>
<interleave>
<optional>
<text/>
</optional>
<optional>
<ref name="everythingandthekitchensink"/>
</optional>
</interleave>
</element>
</define>
<start>
<ref name="everythingandthekitchensink"/>
</start>
;)
SoC at its very best, and totally useless for both validation *and*
documentation. incidentally, it pretty much reflects the current state,
except that it is hierarchic :-D
my suggestion is extensible, but it requires an element hierarchy for
that - as you said, that's not desirable for internal representation.
so how about this:
we define a grammar that can contain some fixed lenya-internal metadata
items from a special namespace "lenya-meta:". these are validatated in a
very thorough way, and must be represented 1:1 in the grammar, leading
to a well-defined api and good documentation.
at the same time, the grammar can contain arbitrary elements from other
namespaces, where people can dump their custom stuff.
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: new LenyaMetaDataGenerator and new namespace?
Posted by Andreas Hartmann <an...@apache.org>.
Hi Jörn,
IMO the problem about this schema is that it is not generic,
i.e. it is not possible to add custom meta data sets without
changing the schema. Additionally, if you convert meta data
to elements, you have to make assumptions, e.g. regarding the
internal storage of workflow versions. This is a concern of
the workflow engine, the meta data component may only read or
write the meta data but not try to parse or understand them.
I'd prefer something like this:
<meta-data xmlns="http://apache.org/lenya/...">
<elements namespace="...">
<element name="foo">
<value>hello</value>
<value>world</value>
</element>
...
</elements>
...
</meta-data>
I understand that this is not as good as your suggestion when
it comes to validation, but IMO we have to use a really extensible
and generic format to render meta data as XML.
WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
new LenyaMetaDataGenerator and new namespace?
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Jörn Nettingsmeier wrote:
> Jörn Nettingsmeier wrote:
>> hi thorsten, hi everyone!
>
> ok, here's my first attempt.
>
> the first patch changes all private methods in LenyaMetaDataGenerator to
> "protected".
>
> the second file is a new subclass, LenyaSaneMetaDataGenerator (NOI
> thorsten ;), that attempts to parse the messy metadata into something
> more xmlish, which can then be handled more gracefully with xslts.
> if you want to try it, just drop it into
> src/java/org/apache/lenya/cms/cocoon/generation.
>
> the third patch activates the new generator in the default sitemap.
> after rebuilding, browse default/authoring/meta&docid=index&lang=en and
> check out the output. for maximum enjoyment, it is advisable to submit
> the current document, otherwise there will be no workflow metadata to view.
before i push this patch into bugzilla for inclusion, a few questions:
* does anyone have objections or suggestions regarding the
implementation? (whitespace will be fixed)
* in the light of another recent discussion about lenya namespaces, what
do you think about creating a new namespace for the output of the
metadata generator, so as not to abuse the page-envelope ns? a
suggestion is attached below, please comment.
* since we're not exactly in code freeze, does it make sense to maintain
this generator as a subclass of thorsten's implementation, or should we
rather merge the two? i would prefer the latter.
btw, i'd like to suggest that in the future we try to create a working
relaxng (or xml schema) for any and all new namespaces that are being
introduced, and only then start coding. there is no better way for
normative documentation imho. it would also be nice to come up with
validation schemas for the namespaces that are already in use....
regards,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
Re: LenyaMetaDataGenerator and java newbie questions..
Posted by Thorsten Scherler <th...@apache.org>.
El dom, 04-06-2006 a las 02:50 +0200, Jörn Nettingsmeier escribió:
> Jörn Nettingsmeier wrote:
> > hi thorsten, hi everyone!
>
> ok, here's my first attempt.
will try to apply your patches this week if nobody beats me to it.
salu2
> the first patch changes all private methods in LenyaMetaDataGenerator to
> "protected".
>
> the second file is a new subclass, LenyaSaneMetaDataGenerator (NOI
> thorsten ;), that attempts to parse the messy metadata into something
> more xmlish, which can then be handled more gracefully with xslts.
> if you want to try it, just drop it into
> src/java/org/apache/lenya/cms/cocoon/generation.
>
> the third patch activates the new generator in the default sitemap.
> after rebuilding, browse default/authoring/meta&docid=index&lang=en and
> check out the output. for maximum enjoyment, it is advisable to submit
> the current document, otherwise there will be no workflow metadata to view.
>
>
> if you wonder why bother at all: i'm doing a "last changed on ... by
> ..." footer with it:
>
> <div id="fusszeile">
> © <i18n:text key="name_uni"/>, <i18n:text key="name_dept"/>.
> <xsl:variable name="date">
> <xsl:value-of
> select="//lenya:meta/lenya:internal/lenya:workflow/lenya:version[last()]/lenya:timestamp/lenya:date"/>
> </xsl:variable>
> <xsl:variable name="time">
> <xsl:value-of
> select="//lenya:meta/lenya:internal/lenya:workflow/lenya:version[last()]/lenya:timestamp/lenya/time"/>
> </xsl:variable>
> <!-- avoid i18n "unparseable date" exception -->
> <xsl:if test="$date and $time">
> <i18n:translate>
> <i18n:text i18n:key="last_change"/>
> <i18n:param name="last_change_date">
> <i18n:date src-pattern="yyyy-mm-dd" locale="{$language}"
> value="{$date}"/>
> <xsl:text>, </xsl:text>
> <i18n:time src-pattern="hh:mm:ss" locale="{$language}"
> value="{$time}"/>
> </i18n:param>
> <i18n:param name="last_change_by">
> <xsl:value-of select="//lenya:meta/lenya:internal/
> lenya:workflow/lenya:version[lenya:event =
> 'edit'][last()]/lenya:user"/>
> </i18n:param>
> </i18n:translate>
> </xsl:if>
> </div>
>
> caveat: i don't know zilch about java, and this thing hasn't seen much
> testing yet. i would welcome suggestions re style and implementation.
>
>
> regards,
>
> jörn
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: LenyaMetaDataGenerator and java newbie questions..
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Jörn Nettingsmeier wrote:
> hi thorsten, hi everyone!
ok, here's my first attempt.
the first patch changes all private methods in LenyaMetaDataGenerator to
"protected".
the second file is a new subclass, LenyaSaneMetaDataGenerator (NOI
thorsten ;), that attempts to parse the messy metadata into something
more xmlish, which can then be handled more gracefully with xslts.
if you want to try it, just drop it into
src/java/org/apache/lenya/cms/cocoon/generation.
the third patch activates the new generator in the default sitemap.
after rebuilding, browse default/authoring/meta&docid=index&lang=en and
check out the output. for maximum enjoyment, it is advisable to submit
the current document, otherwise there will be no workflow metadata to view.
if you wonder why bother at all: i'm doing a "last changed on ... by
..." footer with it:
<div id="fusszeile">
© <i18n:text key="name_uni"/>, <i18n:text key="name_dept"/>.
<xsl:variable name="date">
<xsl:value-of
select="//lenya:meta/lenya:internal/lenya:workflow/lenya:version[last()]/lenya:timestamp/lenya:date"/>
</xsl:variable>
<xsl:variable name="time">
<xsl:value-of
select="//lenya:meta/lenya:internal/lenya:workflow/lenya:version[last()]/lenya:timestamp/lenya/time"/>
</xsl:variable>
<!-- avoid i18n "unparseable date" exception -->
<xsl:if test="$date and $time">
<i18n:translate>
<i18n:text i18n:key="last_change"/>
<i18n:param name="last_change_date">
<i18n:date src-pattern="yyyy-mm-dd" locale="{$language}"
value="{$date}"/>
<xsl:text>, </xsl:text>
<i18n:time src-pattern="hh:mm:ss" locale="{$language}"
value="{$time}"/>
</i18n:param>
<i18n:param name="last_change_by">
<xsl:value-of select="//lenya:meta/lenya:internal/
lenya:workflow/lenya:version[lenya:event =
'edit'][last()]/lenya:user"/>
</i18n:param>
</i18n:translate>
</xsl:if>
</div>
caveat: i don't know zilch about java, and this thing hasn't seen much
testing yet. i would welcome suggestions re style and implementation.
regards,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736