> Hmmm, I don't quite see the link between your concerns and the > repository. Maybe you can give an example? > > Thanks! > > -- Andreas
I knew this would become difficult. Let me try explaining this in a different way: >> Compare the structure (especially directory layout and filenames) in the >> file based repository of Lenya today with the URL structure of the live >> and authoring section of a Lenya website. >> >> www.mysite.com/producs/overview.html >> >> will *not* be a file named overview in a folder called products today. > > Hmmm, how is this related to this discussion? It is an example of that fact that the virtual directory / URI layout of the site that is visible to the outside and the current Lenya internal filesystem layout in pubs/<mypub>/content as well as pubs/<mypub>/resources are different and not a 1:1 mapping. In fact, there is quite a complex relationship mapping a URI from the outside to an actual storage location. Some of that mapping is done in Java, some is done in the sitemap. These are two structures. We are about to introduce another one for JCR as we had a discussion that it will probably not a good use of a JCR repository to just mimic the filesystem 1:1 there. The structure that the current Apache website update and publishing process requires is just another structure, isn't it? > Not yet, but it is a requirement of Doco, and people are interested > in implementing this feature in the near future (see thread by > Roos Gardler, "Finally creating Doco") Can't they do this in form of a JCR backend? That way their work could even be leveraged beyond Lenya. > What's a "different root"? If some stuff is in /home/torsten and some stuff is in /opt/users/andreas, then this is a different (filesystem) root. >> What I am concerned with for quite some time is our URI mangling magic >> stuff. IMO he have way too much semantics and implicit contracts in our >> URIs, especially when it comes to embedding (a page and pictures on the >> page) or linking pieces (internal and external links) together. > > OK, but this is not related to the storage mechanism, is it? I think it is: Whenever I link nodes of content I need a system of referencing them. To say it very concrete: You have to put something into the href attribute. And this something needs to make sense in any place where the document shows up and the href needs to be deferenced. Therefore inside Lenya the path from page A to picture B might be different than it will be in a static export of the site to HTML than it might be in a static export of the site in XDoc. Am I wrong? Another way of thinking about this is: - Does Lenya own the storage repository and can dictate where it's putting what? This is what it is today. Or: - Can we teach Lenya to edit documents that it does not own and that are sitting on some external storage with a given, predefined directory layout structure (i.e. the SVN of the Forrest source of Apache sites). If you want to use Lenya to edit the content of an XDoc Apache website, you need the latter, don't you? The structure is given and you would even have to support a different way of handling the sitemap, which would no longer be Lenya's sitemap.xml but Forrest's site.xml. (Which is sort of pseudo-XML which will make it pretty funny IMO.) Ok, the Doco project might have sorted that all out. Again, apologies for not keeping up with the discussion here. On a separate but related topic: How do they plan to edit XDoc in Lenya? Regards, Torsten Torsten Schlabach wrote: >> Hi, >> >> J. Wolfgang Kaltz wrote: >> >>>IIUC moving to a "JCR-only" approach means that only content backends >>>which implement JCR (so right now only Jackrabbit) may be used for >>>storing content which is handled by Lenya ? >> >> >>>Other repositories: what about svn ? Wouldn't moving to JCR-only mean we >>>can no longer support svn as a backend, and thus use Lenya for Apache >>>sites ? IMO that would be a real shame - please enlighten me if I got >>>something mixed up :) >> >> >> Aren't we start to mix up things here? To me, the internal storage of >> content pieces in Lenya at authoring time on one hand and a static >> export >> of a site or pieces of a site are two quite different issues. >> >> Compare the structure (especially directory layout and filenames) in the >> file based repository of Lenya today with the URL structure of the live >> and authoring section of a Lenya website. >> >> www.mysite.com/producs/overview.html >> >> will *not* be a file named overview in a folder called products today. > > Hmmm, how is this related to this discussion? > > >> And a relative link to images/pro01small.jpg in the above mentioned page >> would resolve to a location in the filesystem of the Lenya instance >> which >> is *not* relative to to the page, but in a different root. >> >> See what I mean? > > Actually, no ... > > What's a "different root"? > > >> And by the way do we support direct editing in SVN today? Where a >> checkin >> of a document becomes a SVN checkin? Did I miss that? > > Not yet, but it is a requirement of Doco, and people are interested > in implementing this feature in the near future (see thread by > Roos Gardler, "Finally creating Doco") > > >> What I am concerned with for quite some time is our URI mangling magic >> stuff. IMO he have way too much semantics and implicit contracts in our >> URIs, especially when it comes to embedding (a page and pictures on the >> page) or linking pieces (internal and external links) together. > > OK, but this is not related to the storage mechanism, is it? > > >> I was hoping that JCR as a well thought through, standardized and in the >> near future well known standard API will provide a chance to clean this >> up >> and improve. For example, by linking not to a pathname but to a UUID. >> This >> would take lots of ambiguity out. > > Hmmm, I don't quite see the link between your concerns and the > repository. Maybe you can give an example? > > Thanks! > > -- Andreas > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
