You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/05/17 09:22:27 UTC
[1.4] DocumentManager.add()
Hi Lenya devs,
some comments on the new DocumentManager.add() method:
> @param parentDocument The parent document.
This must be optional to allow creation of top-level documents.
Should we allow to pass null objects? Then it should be noted in
the javadoc comment.
> @param newDocumentNodeName the name of the node representing the new
> document
> @param newDocumentId the id of the new document
Why do we need both nodeName and documentId?
Actually the document ID should be sufficient, that would even
mean that the parent is unambigously defined.
> @param documentTypeName the document type (aka resource type) of the
> new document
Why don't we pass a DocumentType object? IMO OO code
should use objects whenever possible and appropriate.
> @param language language of the new document
> @param navigationTitle navigation title
> @param initialContentsURI an URI from which initial contents for the
> new document can be read. Optional parameter; may be set to
> <code>null</code>,
> in which case the default initial sample as configured in
> <code>doctypes.xconf</code> will be used.
> @param nodeType the node type, as defined by the constants in {@link
> org.apache.lenya.cms.authoring.NodeCreatorInterface
> NodeCreatorInterface}
Do we really need the NodeType concept? What is it used for?
Is it even possible to obtain the node type of a document through
the API?
> @param parameters any parameters the caller needs to pass to the creator
Can't we get rid of that? IMO it's a bad practise to allow polymorphism
on the basis of arbitrary parameter sets.
> @param useSiteManager set to true if the site manager is used in the
> publication; if set the site manager will be notified about the new
> document
IMO the site manager must be mandatory.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Gregor J. Rothfuss wrote:
>
>> Andreas Hartmann wrote:
>>
>>> IMO that is bad design. The framework has to present an unambigous API.
>>> There should be no "most cases" approach - if you want a task done
>>> that's
>>> not supported by the framework, you can't use the framework. In this
>>> case
>>> the framework must be extensible. The question is if usecase overriding
>>> is convenient enough or if we have to find a simpler mechanism.
>>>
>>> It is fine with me to keep the Creator interface, as long as we remove
>>> the parameter map. But, to be honest, I see a danger of misuse, because
>>> people might try to pass information to the creator using adventurous
>>> approaches like the session. If we can predict an interface to be
>>> insufficient, we should ask ourselves if the interface should be
>>> introduced
>>> (or, in this case, kept) at all.
>>
>>
>>
>> failure to come up with a creator interface in the past clearly
>> indicates that it is not something that is easily generalizable, and
>> should therefore not be an interface.
>
>
>
> Nearly every editor supports "Save As", which basically means saving the
> content
> at a specific path (within a repository), whereas the editor normally
> starts of a template.
I have some trouble understanding this.
Would you mind explaining it more detailed, or even expressing it as a scenario?
-- Andreas
> I don't see any reason why Lenya shouldn't support an interface for that
> and people need to rebuild it every time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> can you please explain that a bit more or even do a sequence diagram?
>
>
> andreas explained it in the original thread
you mean
http://www.mail-archive.com/dev@lenya.apache.org/msg00463.html
?
this doesn't explain it or at least I don't understand how it should work.
Can anyone explain how a document is supposed to be created or at least
what best
practice is supposed to be?
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> can you please explain that a bit more or even do a sequence diagram?
andreas explained it in the original thread
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> Nearly every editor supports "Save As", which basically means saving
>> the content
>> at a specific path (within a repository), whereas the editor normally
>> starts of a template.
>> I don't see any reason why Lenya shouldn't support an interface for
>> that and people need to rebuild it every time.
>
>
> DocumentManager.add(Document)
>
> how you build the document is up to the implementation
can you please explain that a bit more or even do a sequence diagram?
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> Nearly every editor supports "Save As", which basically means saving the
> content
> at a specific path (within a repository), whereas the editor normally
> starts of a template.
> I don't see any reason why Lenya shouldn't support an interface for that
> and people need to rebuild it every time.
DocumentManager.add(Document)
how you build the document is up to the implementation
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>> IMO that is bad design. The framework has to present an unambigous API.
>> There should be no "most cases" approach - if you want a task done
>> that's
>> not supported by the framework, you can't use the framework. In this
>> case
>> the framework must be extensible. The question is if usecase overriding
>> is convenient enough or if we have to find a simpler mechanism.
>>
>> It is fine with me to keep the Creator interface, as long as we remove
>> the parameter map. But, to be honest, I see a danger of misuse, because
>> people might try to pass information to the creator using adventurous
>> approaches like the session. If we can predict an interface to be
>> insufficient, we should ask ourselves if the interface should be
>> introduced
>> (or, in this case, kept) at all.
>
>
> failure to come up with a creator interface in the past clearly
> indicates that it is not something that is easily generalizable, and
> should therefore not be an interface.
Nearly every editor supports "Save As", which basically means saving the
content
at a specific path (within a repository), whereas the editor normally
starts of a template.
I don't see any reason why Lenya shouldn't support an interface for that
and people need to rebuild it every time.
Michi
>
>
> +1 for removing it
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> IMO that is bad design. The framework has to present an unambigous API.
> There should be no "most cases" approach - if you want a task done that's
> not supported by the framework, you can't use the framework. In this case
> the framework must be extensible. The question is if usecase overriding
> is convenient enough or if we have to find a simpler mechanism.
>
> It is fine with me to keep the Creator interface, as long as we remove
> the parameter map. But, to be honest, I see a danger of misuse, because
> people might try to pass information to the creator using adventurous
> approaches like the session. If we can predict an interface to be
> insufficient, we should ask ourselves if the interface should be introduced
> (or, in this case, kept) at all.
failure to come up with a creator interface in the past clearly
indicates that it is not something that is easily generalizable, and
should therefore not be an interface.
+1 for removing it
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Gregor J. Rothfuss wrote:
>
>> Michael Wechner wrote:
>>
>>> I don't think we should get rid of the creator interface altogether.
>>
>>
>>
>> i think we should. as explained in the other thread, it is too generic
>> to be useful. an array of strings is not an interface you can rely on.
>
>
>
> just because the current/old API isn't considered very good, is no
> reason to drop
> the API completely.
>
> One wants to create or import content into Lenya (how else do you want
> to get started otherwise ...) and in most cases it's the same methods
> all the time.
Yes, but IIUC that means "we build the framework so that it can handle
most cases easily, and for the other cases we provide a workaround in
the form of a parameter map."
IMO that is bad design. The framework has to present an unambigous API.
There should be no "most cases" approach - if you want a task done that's
not supported by the framework, you can't use the framework. In this case
the framework must be extensible. The question is if usecase overriding
is convenient enough or if we have to find a simpler mechanism.
It is fine with me to keep the Creator interface, as long as we remove
the parameter map. But, to be honest, I see a danger of misuse, because
people might try to pass information to the creator using adventurous
approaches like the session. If we can predict an interface to be
insufficient, we should ask ourselves if the interface should be introduced
(or, in this case, kept) at all.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> I don't think we should get rid of the creator interface altogether.
>
>
> i think we should. as explained in the other thread, it is too generic
> to be useful. an array of strings is not an interface you can rely on.
just because the current/old API isn't considered very good, is no
reason to drop
the API completely.
One wants to create or import content into Lenya (how else do you want
to get started otherwise ...) and in most cases it's the same methods
all the time.
That's how a framework and APIs emerge ....
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> I don't think we should get rid of the creator interface altogether.
i think we should. as explained in the other thread, it is too generic
to be useful. an array of strings is not an interface you can rely on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Leaves and branches
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> At the moment we don't have this repository abstraction, we just
> operate on sources.
exactly, and it would be a mistake to expose storage details in the API.
who cares if nodes are stored as folders or attributes internally?
> But anyway, IMO the leaf/branch issue on the repository side is not
> related to the Creator interface. The Creator is related to the site
> structure, not to the internal representation of the files. The user
> doesn't care whether a document is stored as a child file/node of
> another document, she cares whether it is a child in the site structure
> (which are entirely different things in the Lenya core, though they can
> be related in specific publications).
+1 and even on the site, it is silly to restrict it, because that means
if you change your mind and want to add child nodes to a leaf node, you
have to start over. which is exactly why we have never used it.
> Imagine you have a tree-like site structure and a flat-file storage.
> The parent-child relations are managed by the SiteManager component.
> So it doesn't make sense to use a leaf/branch concept on the file system
> (storage), but the SiteManager has to know the difference between a leaf
> and a branch. At the moment, there is no such concept. If we introduce
> it, we're restricted to trees again (what about topic maps etc.?).
-1 for introducing it
> But if someone uses the underscore instead of the slash to separate
> parents from children, the Creator has no chance to interfere:
>
> /foo_leaf
> /foo_leaf_bar <- allowed by the creator
it is wrong to infer structure from the URI space. URI are opaque:
http://www.w3.org/2001/tag/2002/0508-intro#URI-meaning
> If you want to create a section that can't have children (for instance
> a "contact" section), you can't use the URL space tree for this
> purpose.
why would you restrict that? sounds like a solution looking for a
problem. an API that tries to second-guess users is destined to fail.
> This means that the above contract is a restriction - it restricts
> the parent-child relation to the slash-separated URL space. I just
> wanted to illustrate that such a contract is very specific, even
> if it does look general on the first glance.
> IMO the most reasonable way to use the leaf/branch concept is to add
> it to the SiteManager, which would mean a restriction tree structures.
-1 based on the grounds above
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Leaves and branches
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> Hi Lenya devs,
>>
>> we're talking about "leaves" and "branches", but I have to admit
>> that I don't know exactly what these terms mean.
>
>
>
> well, one could also use the terms
>
> files/folders (resp. directories)
>
> or
>
> resources/collections (WebDAV)
>
> or
>
> jcr-properties/jcr-nodes (JCR)
Hmmm, that would mean to introduce a general concept that could
be applied to various specific implementations. This requires a
general abstraction layer above these implementations which contains
the notion of leaves and branches:
+---------+
| Creator |
+---------+
|
+-----------------------+
| tree-based repository |
+-----------------------+
| | |
+-------+ +-----+ +--------+
| Files | | JCR | | WebDAV |
+-------+ +-----+ +--------+
At the moment we don't have this repository abstraction, we just
operate on sources.
BTW, IIUC WebDAV is rather an interface to provide a client-side
abstraction, whereas JCR and Files are an internal storage mechanism.
I could imagine something like
+-----------+
| Client |
+-----------+
|
v
+-----------+
| WebDAV |
+-----------+
|
| - some arbitrary mapping
v
+------------------------------+
| repository (JCR, Files, ...) |
+------------------------------+
Or did I get this entirely wrong?
But anyway, IMO the leaf/branch issue on the repository side is not
related to the Creator interface. The Creator is related to the site
structure, not to the internal representation of the files. The user
doesn't care whether a document is stored as a child file/node of
another document, she cares whether it is a child in the site structure
(which are entirely different things in the Lenya core, though they can
be related in specific publications).
Imagine you have a tree-like site structure and a flat-file storage.
The parent-child relations are managed by the SiteManager component.
So it doesn't make sense to use a leaf/branch concept on the file system
(storage), but the SiteManager has to know the difference between a leaf
and a branch. At the moment, there is no such concept. If we introduce
it, we're restricted to trees again (what about topic maps etc.?).
>> IIUC leaf/branch are used to distinguish node types in a tree-like
>> structure. In Lenya, there's no general concept of a tree, apart
>> from the tree implied by the URL space:
>>
>>
>> /foo/bar/index
>> /foo/baz/index
>> /foo/baz/xyz
>>
>> foo
>> / \
>> bar baz
>> / / \
>> index index xyz
>>
>>
>> If we're talking about this tree, then it would be possible to introduce
>> the leaf/branch concept in the framework. But that leads to a
>> restriction:
>>
>> It is not possible to prevent the creation of nodes which are not
>> URL tree children of the current document.
>>
>> Assume you have a URI structure like this:
>>
>> /news
>> /news_page1
>> /news_page2
>> /tv
>> /tv_page1
>> /tv_page2
>> /...
>>
>> where /news is the main page of a section and other pages are
>> separated using the underscore character. In this case it would not
>> be possible to restrict creation using the URL space tree.
>
>
>
> I don't really understand what the restriction is resp. what cannot
> be restricted. Can you give another example?
OK, I'll try :)
Lets assume that Lenya states the following contract:
"A tree is formed by the URL space. A child node is separated from
the parent node by a slash (/). A leaf node may have no children."
This means that the Creator can avoid the following:
/foo/leaf
/foo/leaf/bar <- not allowed! error message
But if someone uses the underscore instead of the slash to separate
parents from children, the Creator has no chance to interfere:
/foo_leaf
/foo_leaf_bar <- allowed by the creator
----
Another example:
Let's assume the SiteManager has a certain knowledge about document
relations which is derived from meta data. If a document is created,
the user adds a meta data term containing the section. For instance
/news
/msg2005-05-14-005 <- meta: section="news"
/tv
/msg2005-05-15-302 <- meta: section="tv"
There is a inherent tree structure which is known by the SiteManager
(for instance the SiteManager will not allow to delete the "news"
node as long as the "msg2005-05-14-005" exists).
If you want to create a section that can't have children (for instance
a "contact" section), you can't use the URL space tree for this
purpose.
----
This means that the above contract is a restriction - it restricts
the parent-child relation to the slash-separated URL space. I just
wanted to illustrate that such a contract is very specific, even
if it does look general on the first glance.
IMO the most reasonable way to use the leaf/branch concept is to add
it to the SiteManager, which would mean a restriction tree structures.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Leaves and branches
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> we're talking about "leaves" and "branches", but I have to admit
> that I don't know exactly what these terms mean.
well, one could also use the terms
files/folders (resp. directories)
or
resources/collections (WebDAV)
or
jcr-properties/jcr-nodes (JCR)
>
> IIUC leaf/branch are used to distinguish node types in a tree-like
> structure. In Lenya, there's no general concept of a tree, apart
> from the tree implied by the URL space:
>
>
> /foo/bar/index
> /foo/baz/index
> /foo/baz/xyz
>
> foo
> / \
> bar baz
> / / \
> index index xyz
>
>
> If we're talking about this tree, then it would be possible to introduce
> the leaf/branch concept in the framework. But that leads to a
> restriction:
>
> It is not possible to prevent the creation of nodes which are not
> URL tree children of the current document.
>
> Assume you have a URI structure like this:
>
> /news
> /news_page1
> /news_page2
> /tv
> /tv_page1
> /tv_page2
> /...
>
> where /news is the main page of a section and other pages are
> separated using the underscore character. In this case it would not
> be possible to restrict creation using the URL space tree.
I don't really understand what the restriction is resp. what cannot
be restricted. Can you give another example?
Michi
>
>
> If we use the leaf/branch concept for the URL space tree, IMO we have
> to be aware that this implies a restriction.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Leaves and branches (was: Re: [1.4] DocumentManager.add())
Posted by Andreas Hartmann <an...@apache.org>.
Hi Lenya devs,
we're talking about "leaves" and "branches", but I have to admit
that I don't know exactly what these terms mean.
IIUC leaf/branch are used to distinguish node types in a tree-like
structure. In Lenya, there's no general concept of a tree, apart
from the tree implied by the URL space:
/foo/bar/index
/foo/baz/index
/foo/baz/xyz
foo
/ \
bar baz
/ / \
index index xyz
If we're talking about this tree, then it would be possible to introduce
the leaf/branch concept in the framework. But that leads to a restriction:
It is not possible to prevent the creation of nodes which are not
URL tree children of the current document.
Assume you have a URI structure like this:
/news
/news_page1
/news_page2
/tv
/tv_page1
/tv_page2
/...
where /news is the main page of a section and other pages are
separated using the underscore character. In this case it would not
be possible to restrict creation using the URL space tree.
If we use the leaf/branch concept for the URL space tree, IMO we have
to be aware that this implies a restriction.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Michael Wechner schrieb:
> (...)
>>
>> Please note that I am not saying it wouldn't make sense to consider
>> treating assets and documents in a more homogeneous manner - quite the
>> contrary, that's why I made a proposal for a new document model in the
>> Wiki. I actually appreciate thoughts in that direction (maybe you
>> would like to comment on that proposal?),
>
>
>
> sure, which one? (It seems to me there are several proposals now)
http://wiki.apache.org/lenya/ProposalContentModel
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
J. Wolfgang Kaltz wrote:
> Michael Wechner schrieb:
> (...)
>
>>> it is ParentChildCreatorInterface (renamed to NodeCreatorInterface),
>>> which is for documents. So I don't see what a parameter for
>>> ParentChildCreatorInterface, which is used for documents, has to do
>>> with assets.
>>
>>
>>
>>
>> one can imagine creating an Asset-Doctype which consists of Meta-Data
>> and a reference to
>> the actual asset
>
>
> It's an interesting idea, but I don't see how this would have worked
> in Lenya, even with the parameter that I removed.
we are currently building this for a customer and it seems to work very
well.
As soon as we have some more experience and time we will try to
generalize it and
donate it to Lenya if the community thinks it's useful, whereas I still
think the JCR
implementation has the highest priority and hope that we are able to
finish what we
have started within the sandbox
> A resource type (formerly known as doctype), it seems to me, is very
> much related to the concept of "editable XML". You define a schema for
> it, you edit it with the XML editors; when rendered Lenya chooses an
> XSLT sheet to transform that XML into some user-friendly
> representation. How could the current Lenya mechanisms work if that
> document was actually a binary file (asset) instead of XML ?
the document is just meta with a link to the actual asset, e.g.
<asset src="lenya.pdf">
<dc:author>...</dc:author>
...
</asset>
>
> Please note that I am not saying it wouldn't make sense to consider
> treating assets and documents in a more homogeneous manner - quite the
> contrary, that's why I made a proposal for a new document model in the
> Wiki. I actually appreciate thoughts in that direction (maybe you
> would like to comment on that proposal?),
sure, which one? (It seems to me there are several proposals now)
> but I just can not see the relationship between removing said
> parameter and that discussion.
well, an assetdoc is not a branch
>
>>>
>>> The "creator" interface in trunk has been changed for several
>>> reasons; but most importantly because it no longer uses
>>> java.io.File. In my understanding, it was a consensus in Lenya to
>>> move away from java.io.File towards URIs and a repository.
>>
>>
>> that's fine, but has nothing to do with the decision to have BRANCH
>> and LEAF or only BRANCHES
>
>
> Indeed; I meant to point out that the interface changes in any case.
> Any custom implementation of a creator will need to be reconsidered.
>
>>
>>> So this means that if anybody has implemented a custom
>>> implementation of a document creator, she would need to change it
>>> anyway.
>>
>>
>> and that's one of the problems. The other problem is that Lenya
>> doesn't allow anymore to
>> create resources of type LEAF
>
>
> I just don't understand what is lost by removing a parameter that the
> core does nothing with. If you want to implement a custom mechanism
> for creating documents which is different than what the core provides
> out-of-the-box, you will need to write custom code (obviously). If you
> want to store an additional parameter somewhere, say "nodeType" or
> whatever, you will need to write that code. The old Lenya did not do
> this for you.
> What Andreas was suggesting in the thread "[1.4] Creator interface" is
> to remove the creator (which has a magic Map of parameters). and write
> the custom code you need in the usecase. So it simply is not the case
> that Lenya would not allow something now that it did allow earlier.
> What I definitely do agree upon, is that the discussion "exactly what
> creation API do we want" is still open.
ok, so let's stop the discussion here and start a new thread at some
later point ;-)
Michi
>
> --
> Wolfgang
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Michael Wechner schrieb:
(...)
>> it is ParentChildCreatorInterface (renamed to NodeCreatorInterface),
>> which is for documents. So I don't see what a parameter for
>> ParentChildCreatorInterface, which is used for documents, has to do
>> with assets.
>
>
>
> one can imagine creating an Asset-Doctype which consists of Meta-Data
> and a reference to
> the actual asset
It's an interesting idea, but I don't see how this would have worked in
Lenya, even with the parameter that I removed. A resource type (formerly
known as doctype), it seems to me, is very much related to the concept
of "editable XML". You define a schema for it, you edit it with the XML
editors; when rendered Lenya chooses an XSLT sheet to transform that XML
into some user-friendly representation. How could the current Lenya
mechanisms work if that document was actually a binary file (asset)
instead of XML ?
Please note that I am not saying it wouldn't make sense to consider
treating assets and documents in a more homogeneous manner - quite the
contrary, that's why I made a proposal for a new document model in the
Wiki. I actually appreciate thoughts in that direction (maybe you would
like to comment on that proposal?), but I just can not see the
relationship between removing said parameter and that discussion.
>>
>> The "creator" interface in trunk has been changed for several reasons;
>> but most importantly because it no longer uses java.io.File. In my
>> understanding, it was a consensus in Lenya to move away from
>> java.io.File towards URIs and a repository.
>
> that's fine, but has nothing to do with the decision to have BRANCH and
> LEAF or only BRANCHES
Indeed; I meant to point out that the interface changes in any case. Any
custom implementation of a creator will need to be reconsidered.
>
>> So this means that if anybody has implemented a custom implementation
>> of a document creator, she would need to change it anyway.
>
> and that's one of the problems. The other problem is that Lenya doesn't
> allow anymore to
> create resources of type LEAF
I just don't understand what is lost by removing a parameter that the
core does nothing with. If you want to implement a custom mechanism for
creating documents which is different than what the core provides
out-of-the-box, you will need to write custom code (obviously). If you
want to store an additional parameter somewhere, say "nodeType" or
whatever, you will need to write that code. The old Lenya did not do
this for you.
What Andreas was suggesting in the thread "[1.4] Creator interface" is
to remove the creator (which has a magic Map of parameters). and write
the custom code you need in the usecase. So it simply is not the case
that Lenya would not allow something now that it did allow earlier. What
I definitely do agree upon, is that the discussion "exactly what
creation API do we want" is still open.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
J. Wolfgang Kaltz wrote:
> Michael Wechner schrieb:
>
>> J. Wolfgang Kaltz wrote:
>>
>>> Michael Wechner schrieb:
>>>
>>>> (...)
>>>> if one wants to use Lenya as "DMS" where WebDAV might be handy as
>>>> well, then it
>>>> definitely makes sense that also a type "leaf/resource" is
>>>> supported, e.g. for
>>>>
>>>> offer.doc
>>>>
>>>> cv.sxw
>>>>
>>>> report.pdf
>>>
>>>
>>>
>>>
>>> In current Lenya, these would assets, not documents, so created via
>>> a different mechanism than the one we were talking about here (the
>>> old ParentChildCreatorInterface)
>>
>>
>>
>>
>> well, I am not talking about the current situation, because the
>> current situation how
>> assets are treated is not very good, because they cannot really be
>> reused, or versioned,
>> or whatsoever.
>
>
> yes, but the interface we are currently discussing simply is not about
> assets,
it is, if you for instance create an Asset-Doctype
> it is ParentChildCreatorInterface (renamed to NodeCreatorInterface),
> which is for documents. So I don't see what a parameter for
> ParentChildCreatorInterface, which is used for documents, has to do
> with assets.
one can imagine creating an Asset-Doctype which consists of Meta-Data
and a reference to
the actual asset
>
> If we are talking about designing a new API for creating documents and
> assets in a similar fashion, then we should talk about that API and
> what its requirements would be. But that is another discussion !
this discussion is leading to discussion about a new API
>
>>
>>>
>>>>
>>>>>
>>>>>> it's not a limitation, it's a flexibility with a default setting,
>>>>>> but I don't
>>>>>> want to start another religious thread here.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> it doesn't offer anything that i can think of. yes its flexible,
>>>>> but useless.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I don't think it's useless at all (see above). Why do you consider
>>>> it useless?
>>>
>>>
>>>
>>>
>>> The thing is that the interface had a parameter of type short, to
>>> distinguish between "leaf" and "branch" node, but this parameter had
>>> no effect. It was not stored anywhere, nor was it accessed at any
>>> point in Lenya.
>>
>>
>>
>>
>> maybe not within the default or the blog publication, but I guess
>> there used or are
>> other third-party publications which make use of it
>
>
> I don't understand what you mean by "make use of it".
use this parameter
> The Lenya core did not do anything with the parameter, did not store
> it, and did not access it.
it's being passed on to the actual creator resp.
src/java/org/apache/lenya/cms/authoring/DefaultCreator.java
src/java/org/apache/lenya/cms/authoring/ParentChildCreatorInterface.java
> So anything a custom publication would have done with this parameter
> would be completely custom, and not make use of anything in the core.
no, the samples might not make use of them anymore
> Please see also below regarding the interface
>
>
>>
>>> So I have removed it, since IMHO interfaces which suggest some
>>> mechanism which doesn't exist are "not a good thing".
>>
>>
>>
>>
>> if the "API" does provide a method, but the samples don't, then that
>> doesn't mean it's not
>> being used
>>
>>> If we need to distinguish leaves and branches for editable
>>> documents, we will have to see how to implement it; but the current
>>> code was not providing this in any case.
>>>
>>> Hope that clarifies things
>>
>>
>>
>>
>> it clarifies why you thought it's obsolete, but I think it should be
>> re-inserted for the reasons of the examples I have provided above.
>
>
> The "creator" interface in trunk has been changed for several reasons;
> but most importantly because it no longer uses java.io.File. In my
> understanding, it was a consensus in Lenya to move away from
> java.io.File towards URIs and a repository.
that's fine, but has nothing to do with the decision to have BRANCH and
LEAF or only BRANCHES
> So this means that if anybody has implemented a custom implementation
> of a document creator, she would need to change it anyway.
and that's one of the problems. The other problem is that Lenya doesn't
allow anymore to
create resources of type LEAF
>
> If my omission of a parameter of type short in the new interface is a
> problem, I can put it back in again; but please see also the other
> thread where Andreas is suggesting to remove the creator interface
> altogether.
I don't think we should get rid of the creator interface altogether.
Michi
>
>
> --
> Wolfgang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Michael Wechner schrieb:
> J. Wolfgang Kaltz wrote:
>
>> Michael Wechner schrieb:
>>
>>> (...)
>>> if one wants to use Lenya as "DMS" where WebDAV might be handy as
>>> well, then it
>>> definitely makes sense that also a type "leaf/resource" is supported,
>>> e.g. for
>>>
>>> offer.doc
>>>
>>> cv.sxw
>>>
>>> report.pdf
>>
>>
>>
>> In current Lenya, these would assets, not documents, so created via a
>> different mechanism than the one we were talking about here (the old
>> ParentChildCreatorInterface)
>
>
>
> well, I am not talking about the current situation, because the current
> situation how
> assets are treated is not very good, because they cannot really be
> reused, or versioned,
> or whatsoever.
yes, but the interface we are currently discussing simply is not about
assets, it is ParentChildCreatorInterface (renamed to
NodeCreatorInterface), which is for documents. So I don't see what a
parameter for ParentChildCreatorInterface, which is used for documents,
has to do with assets.
If we are talking about designing a new API for creating documents and
assets in a similar fashion, then we should talk about that API and what
its requirements would be. But that is another discussion !
>
>>
>>>
>>>>
>>>>> it's not a limitation, it's a flexibility with a default setting,
>>>>> but I don't
>>>>> want to start another religious thread here.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> it doesn't offer anything that i can think of. yes its flexible, but
>>>> useless.
>>>
>>>
>>>
>>>
>>>
>>> I don't think it's useless at all (see above). Why do you consider it
>>> useless?
>>
>>
>>
>> The thing is that the interface had a parameter of type short, to
>> distinguish between "leaf" and "branch" node, but this parameter had
>> no effect. It was not stored anywhere, nor was it accessed at any
>> point in Lenya.
>
>
>
> maybe not within the default or the blog publication, but I guess there
> used or are
> other third-party publications which make use of it
I don't understand what you mean by "make use of it". The Lenya core did
not do anything with the parameter, did not store it, and did not access
it. So anything a custom publication would have done with this parameter
would be completely custom, and not make use of anything in the core.
Please see also below regarding the interface
>
>> So I have removed it, since IMHO interfaces which suggest some
>> mechanism which doesn't exist are "not a good thing".
>
>
>
> if the "API" does provide a method, but the samples don't, then that
> doesn't mean it's not
> being used
>
>> If we need to distinguish leaves and branches for editable documents,
>> we will have to see how to implement it; but the current code was not
>> providing this in any case.
>>
>> Hope that clarifies things
>
>
>
> it clarifies why you thought it's obsolete, but I think it should be
> re-inserted for the reasons of the examples I have provided above.
The "creator" interface in trunk has been changed for several reasons;
but most importantly because it no longer uses java.io.File. In my
understanding, it was a consensus in Lenya to move away from
java.io.File towards URIs and a repository. So this means that if
anybody has implemented a custom implementation of a document creator,
she would need to change it anyway.
If my omission of a parameter of type short in the new interface is a
problem, I can put it back in again; but please see also the other
thread where Andreas is suggesting to remove the creator interface
altogether.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
> well, I am not talking about the current situation, because the current
> situation how
> assets are treated is not very good, because they cannot really be
> reused, or versioned,
> or whatsoever.
Just a heads up - in 1.4 assets are versioned internally, though the
versions are not accessible through the GUI.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
J. Wolfgang Kaltz wrote:
> Michael Wechner schrieb:
>
>> (...)
>> if one wants to use Lenya as "DMS" where WebDAV might be handy as
>> well, then it
>> definitely makes sense that also a type "leaf/resource" is supported,
>> e.g. for
>>
>> offer.doc
>>
>> cv.sxw
>>
>> report.pdf
>
>
> In current Lenya, these would assets, not documents, so created via a
> different mechanism than the one we were talking about here (the old
> ParentChildCreatorInterface)
well, I am not talking about the current situation, because the current
situation how
assets are treated is not very good, because they cannot really be
reused, or versioned,
or whatsoever.
>
>>
>>>
>>>> it's not a limitation, it's a flexibility with a default setting,
>>>> but I don't
>>>> want to start another religious thread here.
>>>
>>>
>>>
>>>
>>> it doesn't offer anything that i can think of. yes its flexible, but
>>> useless.
>>
>>
>>
>>
>> I don't think it's useless at all (see above). Why do you consider it
>> useless?
>
>
> The thing is that the interface had a parameter of type short, to
> distinguish between "leaf" and "branch" node, but this parameter had
> no effect. It was not stored anywhere, nor was it accessed at any
> point in Lenya.
maybe not within the default or the blog publication, but I guess there
used or are
other third-party publications which make use of it
> So I have removed it, since IMHO interfaces which suggest some
> mechanism which doesn't exist are "not a good thing".
if the "API" does provide a method, but the samples don't, then that
doesn't mean it's not
being used
> If we need to distinguish leaves and branches for editable documents,
> we will have to see how to implement it; but the current code was not
> providing this in any case.
>
> Hope that clarifies things
it clarifies why you thought it's obsolete, but I think it should be
re-inserted for the reasons of the examples I have provided above.
Michi
>
> --
> Wolfgang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
J. Wolfgang Kaltz wrote:
> The thing is that the interface had a parameter of type short, to
> distinguish between "leaf" and "branch" node, but this parameter had no
> effect. It was not stored anywhere, nor was it accessed at any point in
> Lenya. So I have removed it, since IMHO interfaces which suggest some
> mechanism which doesn't exist are "not a good thing". If we need to
> distinguish leaves and branches for editable documents, we will have to
> see how to implement it; but the current code was not providing this in
> any case.
>
> Hope that clarifies things
it does, +1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Michael Wechner schrieb:
> (...)
> if one wants to use Lenya as "DMS" where WebDAV might be handy as well,
> then it
> definitely makes sense that also a type "leaf/resource" is supported,
> e.g. for
>
> offer.doc
>
> cv.sxw
>
> report.pdf
In current Lenya, these would assets, not documents, so created via a
different mechanism than the one we were talking about here (the old
ParentChildCreatorInterface)
>
>>
>>> it's not a limitation, it's a flexibility with a default setting, but
>>> I don't
>>> want to start another religious thread here.
>>
>>
>>
>> it doesn't offer anything that i can think of. yes its flexible, but
>> useless.
>
>
>
> I don't think it's useless at all (see above). Why do you consider it
> useless?
The thing is that the interface had a parameter of type short, to
distinguish between "leaf" and "branch" node, but this parameter had no
effect. It was not stored anywhere, nor was it accessed at any point in
Lenya. So I have removed it, since IMHO interfaces which suggest some
mechanism which doesn't exist are "not a good thing". If we need to
distinguish leaves and branches for editable documents, we will have to
see how to implement it; but the current code was not providing this in
any case.
Hope that clarifies things
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> I think it still makes sense, especially in the case of asset
>> management system.
>
>
> what do you mean?
if one wants to use Lenya as "DMS" where WebDAV might be handy as well,
then it
definitely makes sense that also a type "leaf/resource" is supported,
e.g. for
offer.doc
cv.sxw
report.pdf
>
>> it's not a limitation, it's a flexibility with a default setting, but
>> I don't
>> want to start another religious thread here.
>
>
> it doesn't offer anything that i can think of. yes its flexible, but
> useless.
I don't think it's useless at all (see above). Why do you consider it
useless?
Also I think it would make a lot of sense to add a "CollectionDoctype"
which doesn't
do much conten-wise, but supports grouping.
Michi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> I think it still makes sense, especially in the case of asset management
> system.
what do you mean?
> it's not a limitation, it's a flexibility with a default setting, but I
> don't
> want to start another religious thread here.
it doesn't offer anything that i can think of. yes its flexible, but
useless.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> J. Wolfgang Kaltz wrote:
>
>>> Do we really need the NodeType concept? What is it used for?
>>> Is it even possible to obtain the node type of a document through
>>> the API?
>>
>>
>> The blog entries use LEAF_NODE at creation; the default pub entries
>> use BRANCH_NODE. I don't know if this has any implications.
>
>
> that is a very old distinction that no longer makes sense.
I think it still makes sense, especially in the case of asset management
system.
> all reasonable implementations are branch nodes (leaf nodes can not
> have child nodes)
you can make the BRANCH type as default
>
> once the creator interface is ripped out, this limitation will
> disappear with it.
it's not a limitation, it's a flexibility with a default setting, but I
don't
want to start another religious thread here.
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Gregor J. Rothfuss schrieb:
> J. Wolfgang Kaltz wrote:
>
>>> Do we really need the NodeType concept? What is it used for?
>>> Is it even possible to obtain the node type of a document through
>>> the API?
>>
>>
>> The blog entries use LEAF_NODE at creation; the default pub entries
>> use BRANCH_NODE. I don't know if this has any implications.
>
>
> that is a very old distinction that no longer makes sense. all
> reasonable implementations are branch nodes (leaf nodes can not have
> child nodes)
A quick test creating Blog entries as BRANCH_NODE shows no problems.
Since getChildType() is actually never called, I will try to remove the
node distinction entirely from the code.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
J. Wolfgang Kaltz wrote:
>> Do we really need the NodeType concept? What is it used for?
>> Is it even possible to obtain the node type of a document through
>> the API?
>
> The blog entries use LEAF_NODE at creation; the default pub entries use
> BRANCH_NODE. I don't know if this has any implications.
that is a very old distinction that no longer makes sense. all
reasonable implementations are branch nodes (leaf nodes can not have
child nodes)
once the creator interface is ripped out, this limitation will disappear
with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
[...]
> Wouldn't that imply that the blog pub should have its own implementation
> of DocumentIdToPathMapper ?
It uses the SingleLanguageIdentityMapper, which is similar to the
DefaultDocumentIdToPathMapper but doesn't add a language suffix to
the source URIs.
> The alternative is to force the blog entries to have the same close
> mapping between ids and uri paths as the default publication, so that
> the DefaultDocumentIdToPathMapper can be used for both publications.
> This is was I was trying to say in my earlier mail, making ids that
> match the source path, such as 2005/05/18/testA
>
> But IIUC this is what you actually did, since the entry path creation
> logic was moved from the blog creator to the blog usecase; this way the
> id "path" is indeed the same as the URI path.
Yes, exactly.
[...]
> Basically my pb started when trying to create a blog entry via URI
> instead of File, and the nodes were not locked, because getSourceURI()
> returned something else for the blog entries than their actual path.
> IIUC that is no longer the case.
OK, I see.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Andreas Hartmann schrieb:
>> (...)
>> I think we have a design problem with the id / uri business. IIUC we
>> have code in the core which assumes ids (meaning, in the default pub,
>> including the parent paths, such as /index/test123/test5) and the uri
>> (meaning, where can the source be found) are basically the same.
>
>
> No, that's not assumed. The relation is clearly defined as follows:
>
>
> Browser URI: /index/test123/test5[...]
>
> |
> | mapping by DocumentBuilder
> |
> v
>
> Document object
> Document ID: /index/test123/test5
> Language: en
>
> |
> | mapping by DocumentIdToPathMapper
> |
> v
>
> Document source URI: /index/test123/test5_en.xml
>
> How the source URI is assembled is only known by the
> DocumentIdToPathMapper.
Thx for explaining
Wouldn't that imply that the blog pub should have its own implementation
of DocumentIdToPathMapper ?
The alternative is to force the blog entries to have the same close
mapping between ids and uri paths as the default publication, so that
the DefaultDocumentIdToPathMapper can be used for both publications.
This is was I was trying to say in my earlier mail, making ids that
match the source path, such as 2005/05/18/testA
But IIUC this is what you actually did, since the entry path creation
logic was moved from the blog creator to the blog usecase; this way the
id "path" is indeed the same as the URI path.
> (...)
>> I guess we have to decide between
>> 1. permit a document id to be completely different from the way the
>> document's URI is constructed.
>
>
> With document's URI do you mean the browser URI?
> That would be a major change ...
No, I meant our internal URI, meaning where to find the source. I
understand now this should be handled by the implementation for
DocumentIdToPathMapper
>
>> 2. decide that knowing a document's id must be sufficient to compute
>> its URI (meaning its internal address, basically
>> lenya://pub-path/document-id)
>
>
> Hmm, I don't understand ... If you have the document object, you can
> resolve its source URI by getSourceURI().
Yes.
Basically my pb started when trying to create a blog entry via URI
instead of File, and the nodes were not locked, because getSourceURI()
returned something else for the blog entries than their actual path.
IIUC that is no longer the case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
[...]
>>> We currently need the parent
>>> - to construct the new URI for a default publication entry. So I
>>> guess for this the parent could be null, in which case we would
>>> simply use "/" as the base for the new entry (just committed that)
>>
>>
>>
>> But isn't this clearly definded by the document ID of the newly
>> created document, or am I missing something?
>
>
> I think we have a design problem with the id / uri business. IIUC we
> have code in the core which assumes ids (meaning, in the default pub,
> including the parent paths, such as /index/test123/test5) and the uri
> (meaning, where can the source be found) are basically the same.
No, that's not assumed. The relation is clearly defined as follows:
Browser URI: /index/test123/test5[...]
|
| mapping by DocumentBuilder
|
v
Document object
Document ID: /index/test123/test5
Language: en
|
| mapping by DocumentIdToPathMapper
|
v
Document source URI: /index/test123/test5_en.xml
How the source URI is assembled is only known by the DocumentIdToPathMapper.
> But this doesn't hold in Blog :
> 1. the IdentityMap.get() calls DefaultDocumentBuilder.buildDocument to
> create an instance of Document. In here, documentId = documentURL
Basically yes.
> 2. then we create a physical representation of the document; how the URI
> is constructed is publication dependent; it's not the same in default &
> blog, which uses a hierarchy based on the current date.
Building the source URI is the responsibility of the DocumentIdToPathMapper.
> So after 1., a call to Document.getSourceURI() is invalid, because the
> pub specific code wasn't yet executed.
Hmm, I don't understand that. Document.getSourceURI() calls the
DocumentIdToPathMapper, which is publication specific.
> This doesn't matter in default
> pub, because the id is constructed the same way as the URI. But it
> doesn't work in blog. Since I wasn't sure how to best resolve this
> situation, for the time being I encapsulated Document instance creation
> + URI computation + node locking + creator call in the same method
> (DocumentManager.add), so we can be sure that for exterior callers such
> as the use cases, there is no danger of inconsistency.
OK, i'll look at the code.
> I guess we have to decide between
> 1. permit a document id to be completely different from the way the
> document's URI is constructed.
With document's URI do you mean the browser URI?
That would be a major change ...
> 2. decide that knowing a document's id must be sufficient to compute its
> URI (meaning its internal address, basically lenya://pub-path/document-id)
Hmm, I don't understand ... If you have the document object, you can
resolve its source URI by getSourceURI().
> Personally, I would favor option 2. The user, when creating a new
> document, provides a node name. But the document id (a Lenya internal
> thing) is constructed the same way that the sources are organized, meaning
> - in default pub, as a path from the home document to this document (as
> is the case now)
> - in blog pub, the id matches the source path, e.g. 2005/05/18/testA
Like already mentioned, this is arbitrary. It is only known by the
DocumentIdToPathMapper.
> BTW this would solve a usability pb of Blog at the same time: since
> currently ids are "flat", this means a user can't create an entry named
> "testA" twice, even if it's on separate days.
>
> Both options would require some careful refactoring anyway; as currently
> there is usecase specific code for determining the new document id, but
> creator implementation specific code for determining the new URI.
>
>>
>>> - to access the DocumentIdentityMap. Like previously said, I don't
>>> understand why the DocumentIdentityMap is accessed via an existing
>>> Document instance. If it were accessed via the Publication, we could
>>> pass that instead.
>>
>>
>>
>> Currently, the publication object is not designed to care about
>> transactions. IMO it shouldn't know anything about identity maps etc.
>
>
> What about the DocumentManager ? Would it make sense to have
> DocumentManager.getIdentityMap() ?
IMO not, because that's not a concern of the document manager.
It works on documents, but has no internal knowledge about the
current transaction.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Andreas Hartmann schrieb:
>> (...)
>> General comment on the changes: the goals were to
>> - ensure Lenya meta-data creation in all use cases
>> - remove usage of java.io.File
>> - document the process & make simplifications if possible
>>
>> Frankly, I still haven't understood all of the existing code involved,
>> so much of the functionality is exactly as it was before (just
>> refactored). As admitted in my previous mail, I definitely agree there
>> is room for improvement / clarification - for the time being I was
>> happy to get the above goals working (I found it quite challenging to
>> get something working at the same time in the default publication and
>> in the blog publication)
>
>
> Thank you for these improvements, they're really appreciated.
> I hope you don't see my comments as criticism, actually I'm very
> happy that you're that active in developing 1.4.
:) I think constructive criticism (which it was) is really important;
I'm a strong believer in step-wise, iterative processes in software
development.
>
>>> > @param parentDocument The parent document.
>>>
>>> This must be optional to allow creation of top-level documents.
>>> Should we allow to pass null objects? Then it should be noted in
>>> the javadoc comment.
>>
>>
>> We currently need the parent
>> - to construct the new URI for a default publication entry. So I guess
>> for this the parent could be null, in which case we would simply use
>> "/" as the base for the new entry (just committed that)
>
>
> But isn't this clearly definded by the document ID of the newly
> created document, or am I missing something?
I think we have a design problem with the id / uri business. IIUC we
have code in the core which assumes ids (meaning, in the default pub,
including the parent paths, such as /index/test123/test5) and the uri
(meaning, where can the source be found) are basically the same.
But this doesn't hold in Blog :
1. the IdentityMap.get() calls DefaultDocumentBuilder.buildDocument to
create an instance of Document. In here, documentId = documentURL
2. then we create a physical representation of the document; how the URI
is constructed is publication dependent; it's not the same in default &
blog, which uses a hierarchy based on the current date.
So after 1., a call to Document.getSourceURI() is invalid, because the
pub specific code wasn't yet executed. This doesn't matter in default
pub, because the id is constructed the same way as the URI. But it
doesn't work in blog. Since I wasn't sure how to best resolve this
situation, for the time being I encapsulated Document instance creation
+ URI computation + node locking + creator call in the same method
(DocumentManager.add), so we can be sure that for exterior callers such
as the use cases, there is no danger of inconsistency.
I guess we have to decide between
1. permit a document id to be completely different from the way the
document's URI is constructed.
2. decide that knowing a document's id must be sufficient to compute its
URI (meaning its internal address, basically lenya://pub-path/document-id)
Personally, I would favor option 2. The user, when creating a new
document, provides a node name. But the document id (a Lenya internal
thing) is constructed the same way that the sources are organized, meaning
- in default pub, as a path from the home document to this document (as
is the case now)
- in blog pub, the id matches the source path, e.g. 2005/05/18/testA
BTW this would solve a usability pb of Blog at the same time: since
currently ids are "flat", this means a user can't create an entry named
"testA" twice, even if it's on separate days.
Both options would require some careful refactoring anyway; as currently
there is usecase specific code for determining the new document id, but
creator implementation specific code for determining the new URI.
>
>> - to access the DocumentIdentityMap. Like previously said, I don't
>> understand why the DocumentIdentityMap is accessed via an existing
>> Document instance. If it were accessed via the Publication, we could
>> pass that instead.
>
>
> Currently, the publication object is not designed to care about
> transactions. IMO it shouldn't know anything about identity maps etc.
What about the DocumentManager ? Would it make sense to have
DocumentManager.getIdentityMap() ?
>>
>> The problem is that publication.getSiteManagerHint() returns null when
>> in the blog publication. I agree we should remove that parameter once
>> the blog pub has a site manager.
>
>
> That should work now.
Confirmed; thx
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>> Hi Lenya devs,
>>
>> some comments on the new DocumentManager.add() method:
>>
>
> General comment on the changes: the goals were to
> - ensure Lenya meta-data creation in all use cases
> - remove usage of java.io.File
> - document the process & make simplifications if possible
>
> Frankly, I still haven't understood all of the existing code involved,
> so much of the functionality is exactly as it was before (just
> refactored). As admitted in my previous mail, I definitely agree there
> is room for improvement / clarification - for the time being I was happy
> to get the above goals working (I found it quite challenging to get
> something working at the same time in the default publication and in the
> blog publication)
Thank you for these improvements, they're really appreciated.
I hope you don't see my comments as criticism, actually I'm very
happy that you're that active in developing 1.4.
>> > @param parentDocument The parent document.
>>
>> This must be optional to allow creation of top-level documents.
>> Should we allow to pass null objects? Then it should be noted in
>> the javadoc comment.
>
> We currently need the parent
> - to construct the new URI for a default publication entry. So I guess
> for this the parent could be null, in which case we would simply use "/"
> as the base for the new entry (just committed that)
But isn't this clearly definded by the document ID of the newly
created document, or am I missing something?
> - to access the DocumentIdentityMap. Like previously said, I don't
> understand why the DocumentIdentityMap is accessed via an existing
> Document instance. If it were accessed via the Publication, we could
> pass that instead.
Currently, the publication object is not designed to care about
transactions. IMO it shouldn't know anything about identity maps etc.
>> > @param newDocumentNodeName the name of the node representing the new
>> > document
>>
>> > @param newDocumentId the id of the new document
>>
>> Why do we need both nodeName and documentId?
>> Actually the document ID should be sufficient, that would even
>> mean that the parent is unambigously defined.
>
>
> The nodeName is used to build the new URI, whereas the newDocumentId is
> used to look up a new instance via the IdentityMap. I suppose these
> could be merged, but was looking understanding of the IdentityMap to
> risk it.
OK, I'll take a deeper look at the code.
[...]
>> > @param parameters any parameters the caller needs to pass to the
>> creator
>>
>> Can't we get rid of that? IMO it's a bad practise to allow polymorphism
>> on the basis of arbitrary parameter sets.
>
>
> It is in the creator interface, and used by the blog entry creator in
> the transformXML() method. I am not sure how the parameters would be
> passed otherwise ?
I'll take a look at this, maybe a pattern can be applied to the
situation.
>> > @param useSiteManager set to true if the site manager is used in the
>> > publication; if set the site manager will be notified about
>> the new
>> > document
>>
>> IMO the site manager must be mandatory.
>
>
> The problem is that publication.getSiteManagerHint() returns null when
> in the blog publication. I agree we should remove that parameter once
> the blog pub has a site manager.
That should work now.
> Thx for your feedback & please make any improvements you feel are
> appropriate !
> I lack understanding of the IdentityMap, site manager & blog pub
> internals to do them at this time.
I'll try to add more docs about the internals when I find the time.
> To me the important things for now
> are that Document.getResourceType() is reliable in all situations (so we
> can remove the DocumentTypeResolver)
IMO it would be valid to throw an exception in getResourceType() if
the document does not exist.
> and that creation goes through
> lenya:// instead of File.
+1
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "J. Wolfgang Kaltz" <jw...@apache.org>.
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> some comments on the new DocumentManager.add() method:
>
General comment on the changes: the goals were to
- ensure Lenya meta-data creation in all use cases
- remove usage of java.io.File
- document the process & make simplifications if possible
Frankly, I still haven't understood all of the existing code involved,
so much of the functionality is exactly as it was before (just
refactored). As admitted in my previous mail, I definitely agree there
is room for improvement / clarification - for the time being I was happy
to get the above goals working (I found it quite challenging to get
something working at the same time in the default publication and in the
blog publication)
>
> > @param parentDocument The parent document.
>
> This must be optional to allow creation of top-level documents.
> Should we allow to pass null objects? Then it should be noted in
> the javadoc comment.
We currently need the parent
- to construct the new URI for a default publication entry. So I guess
for this the parent could be null, in which case we would simply use "/"
as the base for the new entry (just committed that)
- to access the DocumentIdentityMap. Like previously said, I don't
understand why the DocumentIdentityMap is accessed via an existing
Document instance. If it were accessed via the Publication, we could
pass that instead.
>
> > @param newDocumentNodeName the name of the node representing the new
> > document
>
> > @param newDocumentId the id of the new document
>
> Why do we need both nodeName and documentId?
> Actually the document ID should be sufficient, that would even
> mean that the parent is unambigously defined.
The nodeName is used to build the new URI, whereas the newDocumentId is
used to look up a new instance via the IdentityMap. I suppose these
could be merged, but was looking understanding of the IdentityMap to
risk it.
>
> > @param documentTypeName the document type (aka resource type) of the
> > new document
>
> Why don't we pass a DocumentType object? IMO OO code
> should use objects whenever possible and appropriate.
Sure, I think it would be just as valid to do it like that. The add()
interface would be shorter, the code in the usecase would be longer;
it's a tradeoff (as usual)
>
> > @param language language of the new document
>
> > @param navigationTitle navigation title
>
> > @param initialContentsURI an URI from which initial contents for the
> > new document can be read. Optional parameter; may be set to
> > <code>null</code>,
> > in which case the default initial sample as configured in
> > <code>doctypes.xconf</code> will be used.
>
> > @param nodeType the node type, as defined by the constants in {@link
> > org.apache.lenya.cms.authoring.NodeCreatorInterface
> > NodeCreatorInterface}
>
> Do we really need the NodeType concept? What is it used for?
> Is it even possible to obtain the node type of a document through
> the API?
The blog entries use LEAF_NODE at creation; the default pub entries use
BRANCH_NODE. I don't know if this has any implications.
>
> > @param parameters any parameters the caller needs to pass to the creator
>
> Can't we get rid of that? IMO it's a bad practise to allow polymorphism
> on the basis of arbitrary parameter sets.
It is in the creator interface, and used by the blog entry creator in
the transformXML() method. I am not sure how the parameters would be
passed otherwise ?
>
> > @param useSiteManager set to true if the site manager is used in the
> > publication; if set the site manager will be notified about
> the new
> > document
>
> IMO the site manager must be mandatory.
The problem is that publication.getSiteManagerHint() returns null when
in the blog publication. I agree we should remove that parameter once
the blog pub has a site manager.
Thx for your feedback & please make any improvements you feel are
appropriate !
I lack understanding of the IdentityMap, site manager & blog pub
internals to do them at this time. To me the important things for now
are that Document.getResourceType() is reliable in all situations (so we
can remove the DocumentTypeResolver) and that creation goes through
lenya:// instead of File.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] DocumentManager.add()
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> Why do we need both nodeName and documentId?
> Actually the document ID should be sufficient, that would even
> mean that the parent is unambigously defined.
+1
> > @param documentTypeName the document type (aka resource type) of the
> > new document
>
> Why don't we pass a DocumentType object? IMO OO code
> should use objects whenever possible and appropriate.
+1
> > @param nodeType the node type, as defined by the constants in {@link
> > org.apache.lenya.cms.authoring.NodeCreatorInterface
> > NodeCreatorInterface}
>
> Do we really need the NodeType concept? What is it used for?
> Is it even possible to obtain the node type of a document through
> the API?
no idea, please explain what nodeType is for?
> > @param parameters any parameters the caller needs to pass to the creator
>
> Can't we get rid of that? IMO it's a bad practise to allow polymorphism
> on the basis of arbitrary parameter sets.
precisely. that is the major brokenness of the current creator interface.
> > @param useSiteManager set to true if the site manager is used in the
> > publication; if set the site manager will be notified about
> the new
> > document
>
> IMO the site manager must be mandatory.
absolutely.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org