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: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
