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