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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
