Summary: | [Kupu] Port Kupu integration to the usecase framework | ||
---|---|---|---|
Product: | Lenya | Reporter: | Torsten Schlabach <tschlabach> |
Component: | Kupu Integration | Assignee: | Lenya Developers <dev> |
Status: | RESOLVED WONTFIX | ||
Severity: | minor | CC: | dev, edith |
Priority: | P1 | ||
Version: | Trunk | ||
Target Milestone: | 2.0.1 | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | |||
Bug Blocks: | 33793 |
Description
Torsten Schlabach
2005-03-01 19:15:06 UTC
i agree with your assessment. if you are prepared to move these to lenya and change the pipelines accordingly, i will remove them from kupu. (In reply to comment #1) > i agree with your assessment. if you are prepared to move these to lenya and > change the pipelines accordingly, i will remove them from kupu. I'd just like to think a bit about where to put it. I mean the directory structure. I would like to try to prepare for moving Kupu to a kind of block if possible. I wonder if that would have an impact on the directory structure. (In reply to comment #2) > I'd just like to think a bit about where to put it. I mean the directory > structure. I would like to try to prepare for moving Kupu to a kind of block if > possible. I wonder if that would have an impact on the directory structure. bxe related things are under resources/misc/bxe, so resources/misc/kupu makes a lot of sense. (In reply to comment #3) > bxe related things are under resources/misc/bxe, so resources/misc/kupu makes a > lot of sense. I don't like the "misc" in there. But its not consequently used anyway. See find . -name bxe -print ./lenya/pubs/blog/resources/misc/bxe ./lenya/pubs/default/resources/misc/bxe ./lenya/xslt/bxe ./lenya/resources/bxe ./lenya/resources/misc/bxe Also one thing is where we put our stuff (the Lenya artifacts) and where to put the kupu tree. For the Lenya artifacts, I wonder if this should be lenya/resources/kupu/xslt or just lenya/xslt/kupu I mean, what exactly is "resources"? Sometimes we use it to store pretty static stuff that get's served like images, css, etc. And then in other places we put xslts under resources. I am thinking of $LENYA_WEBAPP/external/... such as $LENYA_WEBAPP/external/kupu $LENYA_WEBAPP/external/bxe $LENYA_WEBAPP/external/foo as the place to link external reositories. This would make it quite clear. On the other hand, the integration between Kupu and Lenya is a two-way street. Kupu provides stuff to Lenya but Lenya also provides stuff to Kupu. This needs to go somewhere as well. How about $LENYA_WEBAPP/export/kupu for this kind of stuff? The convention would be: - Whatever is in $LENYA_WEBAPP/export is stuff which Lenya provides to plugins. - Whetever is in $LENYA_WEBAPP/external does not come from the Lenya developers but from a 3rd party (In reply to comment #4) the reason why it is in misc is because resources/kupu and resources/bxe are taken by svn:external already (for the checkout) i don't think we should do a "moving stuff around" excercise at this point. (In reply to comment #5) > i don't think we should do a "moving stuff around" excercise at this point. Why? We will get a much clearer structure that way. It's easier to do it know then it will be at a later point in time. I would have to touch all the references anyway as the apache-lenya folder has to move, as we agreed upon. (In reply to comment #6) > (In reply to comment #5) > > i don't think we should do a "moving stuff around" excercise at this point. > > Why? > We will get a much clearer structure that way. > It's easier to do it know then it will be at a later point in time. > I would have to touch all the references anyway as the apache-lenya folder has > to move, as we agreed upon. we did a big directory structure reorg between 0.8 and 1.0. while it has improved things (see http://cvs.apache.org/viewcvs.cgi/cocoon-lenya/src/webapp/lenya/pubs/docs/content/live/bas-dir.xml?hideattic=0&rev=1.3&view=markup to get a taste how it used to be..), we were never able to put files into the one right place. whether you order them by file type, purpose or another criteria, you'll always find cases that do not fit. and trying to find the perfect directory structure is bikeshedding in my opinion while incurring unnecessary migration costs at the same time. so in summary, i do not believe that a new structure is sufficiently better to justify the costs of migration. i started to port the kupu usecase to the usecase framework. there is now a editors.kupu.Kupu class, but the view still needs to be changed (taking the concerns in this thread into account), the usecase name needs to be changed from kupu to edit.kupu, all menus need to be changed to reflect that *** Bug 37978 has been marked as a duplicate of this bug. *** i see that we now have a kupu module, but the kupu usecase that gets actually registered is still the one in usecases/edit/kupu/kupu.jx. what's the state of kupu modularization? i think it should be done before 1.4 goes out. with the addition of jonathan's patch, all kupu resources are now in the kupu module. (see bug 39890) all that's left to do is port kupu to use the 1.4 usecase framework. but i'm not sufficiently interested in kupu to try that. afaic, legacy code is ok as long as it's self-contained and does not clutter global namespaces, sitemaps etc. hence, i'm reducing the severity to "minor". change back if you disagree. (In reply to comment #0) > The XSL and HTML stuff for Kupu integration which lives in the apache-lenya > directory of the Kupu SVN needs to be moved to the Lenya-SVN. There are several > reasons: > > 1. It's cleaner. If someone is using Kupu without Lenya why should he have this > lying around? > 2. The stuff in that directory is specific to a Lenya version. For example, page > envelope parameter names have changed in Lenya from 1.2 to 1.4. As some of these > parameters are used in there as well we need separate versions for 1.2 and 1.4 > (example: node-id versus document-name). Are these original concerns addressed? i'm moving this out of the 1.4 queue. we should address that some time, but not necessarily now. Kupu will not be supported in future versions. |