Re: my trip through the view-related pipelines
:)
First of all good to have this fresh wind blowing in my face. ;-)
I really like having you on board.
[NOTE: I snipped the mail apart to fit my explanations and visions of
views]
[NOTE: I assume we are using jx for the forrest:structurer]
Long Version:
* The Request
URL request is matched by the following match in viewHelper.xhtml
plugin. This kicks
off views.
The situation that we have right now is that:
map:match pattern=*.html
map:generate src=cocoon://{1}.page/
map:transform src=cocoon://getStylesheet.xhtml.{1}
map:parameter name=path value={0}/
/map:transform
map:transform src=resources/stylesheets/strip_namespaces.xsl/
map:serialize type=xhtml/
/map:match
Which should become:
xmap:
map:match pattern=**.html
map:generate src={lm:{0}.model.xml}/
map:transform src={lm:{0}.viewHelper.xsl}
map:serialize type=xml/
map:match/
lm:
match pattern=**.model.xml
location src=cocoon://get.{0} /
/match
match pattern=**.viewHelper.xsl
location src=cocoon://get.{0} /
/match
** The Generator Call Chain
The following is a look at the call chain from the generator in the
original request match whose source is cocoon://{1}.page.
The situation that we have right now is that:
1. The generator pulls gets its source from the following in the
internal.view plugin:
map:match pattern=*.page
map:aggregate element=site
map:part src=cocoon://skinconf.xml/
map:part src=cocoon://build-info/
map:part src=cocoon://tab-{1}.html/
map:part src=cocoon://menu-{1}.html/
map:part src=cocoon://body-{1}.html/
map:part src=cocoon:/prepare.view-nugget.{1}/
/map:aggregate
map:serialize type=xml/
/map:match
As you might expect, this results in a really large page that just
concatenates the different piece-parts -- some obvious, some maybe
not.
That is why we have to only request what we need. More then half of the
stuff that you bulled point now is either not need or not used or to
inflexible to override. I will show possible refactoring ideas.
skinconf.xml - colors, familiar stuff
forrest:contracts/ and forrest:properties/ is completely replacing
the need for having the skinconf.xml. There are still contracts
dependent on it but they need to be refactored anyway (xhmtl2). We
should use the chance to get rid of skinconf.xml. Half of the stuff is
about placing elements in the old fashion skin the other half is adding
the properties of the outcome (e.g. copyright notice).
build-info - info element with version, project-skin, etc.
Should become:
forrest:contract name=siteinfo-build
forrest:properties contract=siteinfo-build
forrest:property name=siteinfo-build
nugget=get.build.info
urlbuild-info/url
/forrest:property
/forrest:properties
/forrest:contract
tab - tabs html chunk
menu - menu html chunk
Should be united as
xmap:
map:match pattern=**.navigation.xml
map:generate src={lm:navigation.xml}/
map:transform src={lm:navigation.xsl}
map:parameter name=request value={1}/
/map:transform
map:serialize type=xml/
map:match/
lm:
match pattern=*.navigation.xml
location src=site.xml /
/match
match pattern=*.navigation.xsl
location src=site2navigation.xsl /
/match
Should be request with e.g. following contract (menu):
forrest:contract name=nav-section
forrest:properties contract=nav-section
forrest:property name=nav-section
nugget=get.navigation
!--NOTE: JX--
url${request}.navigation.xml/url
/forrest:property
/forrest:properties
/forrest:contract
body - content wrapped in a div id=content
Which should become:
xmap:
map:match pattern=**.source.xml
map:generate src={lm:{0}}/
map:serialize type=xml/
map:match/
lm:
match pattern=**.source.xml
location src=get.{0} /
/match
or (depending whether you want the original source or the xdocs
[internal format])
Which should become:
xmap:
map:match pattern=**.internal.xml
map:generate src={lm:{0}}/
map:serialize type=xml/
map:match/
lm:
match pattern=**.internal.xml
location src=get.{0} /
/match
prepare-view-nugget.{1} - see next step
Which should be the only thing left in the above match=**.page:
xmap:
map:match pattern=**.model.xml
map:generate src={lm:{0}}/
map:serialize type=xml/
map:match/
lm:
match pattern=**.model.xml
location src=get.{0} /
/match
Example:
http://localhost:/index.page
2. This is just an aggregation of all the content that might be
useful. Unique to views really the last part,
prepare.view-nugget.{1}.
Yes, this unique part is as well the only thing that should be needed.
The other aggregation parts should be request by contracts on demand.
This resolves to the following in the same
internal.view plugin.
map:match pattern=prepare.view-nugget.**
map:generate src=cocoon:/prepare.view.{1}/
map:transform src=resources/stylesheets/prepare.view.xsl
map:parameter name=view
Re: Blank page of xhtml2_subset.html
Still not working, I did again in this order :- 1) svn up (rev 279554 now) 2) checked /main/webapp/WEB-INF/xconf/forrest-core.xconf making sure changes were correct. a) svn diff of forrest-core.xconf.diff says :- Index: main/webapp/WEB-INF/xconf/forrest-core.xconf === --- main/webapp/WEB-INF/xconf/forrest-core.xconf (revision 279554) +++ main/webapp/WEB-INF/xconf/forrest-core.xconf (working copy) @@ -130,8 +130,8 @@ whiteboard-plugins-src@forrest.home@/whiteboard/plugins/whiteboard-plugins-src plugins@forrest.home@/build/plugins/plugins locationmap@context.home@/locationmap.xml/locationmap - view-internal@forrest.home@/build/plugins/org.apache.forrest.plugin.internal.view/view-internal - view-themes@forrest.home@/build/plugins/org.apache.forrest.plugin.internal.view/resources/views/view-themes + view-internal@forrest.home@/build/plugins/org.apache.forrest.plugin.internal.xhtml2/view-internal + view-themes@forrest.home@/build/plugins/org.apache.forrest.plugin.internal.xhtml2/resources/views/view-themes theme-ext.fv/theme-ext themedefault/theme /values 3) build clean, 4) cd whiteboard/plugins/org.apache.forrest.plugin.internal.xhtml2 5) ant local-deploy 6) forrest run And I get a blank page (no errors no nothing). When I view:source all the code is there - xhtml1-strict now I see , good, when I can see it ! An svn status produced :- ? basic.css.diff ? skinconf.xml.diff ? faq.html.diff ? .forrest-core.xconf.diff.swp ? forrest-core.xconf.diff ? status.txt ? faq.xml.diff ? screen.css.diff M main\fresh-site\forrest.properties ? main\webapp\.upload-dir M main\webapp\WEB-INF\xconf\forrest-core.xconf ? main\webapp\skins\leather-dev\css\basic.css.diff M main\webapp\skins\pelt\css\screen.css M main\webapp\skins\pelt\xslt\html\site2xhtml.xsl M main\webapp\skins\common\xslt\html\site2xhtml.xsl M main\webapp\sitemap.xmap ? whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\build ? whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset_old.xml ? whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset.xml.mine ? whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset.xml.r279017 C whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset.xml ? whiteboard\plugins\org.apache.forrest.plugin.output.viewHelper.xhtml\build ? whiteboard\plugins\org.apache.forrest.plugin.input.viewHelper.xhtml.ls\build ? whiteboard\plugins\org.apache.forrest.plugin.internal.view\build I think I might delete all the xhtml2_subset.* versions and do another svn up. Cant see anything else wrong. Gav... - Original Message - From: David Crossley [EMAIL PROTECTED] To: dev@forrest.apache.org Sent: Thursday, September 08, 2005 8:17 AM Subject: Re: Blank page of xhtml2_subset.html | Gav wrote: | Have made the changes to forrest-core.xconf after an svn up, build clean etc | | http://localhost:/samples/xhtml2_subset.html | | now gives me a blank page, although the source is clearly there. | http://localhost:/samples/xhtml2_subset.xml comes up | with a not found error now too. | | I think I must have broken something. | | Any ideas ? | | Today's SVN works for me. Both /index.html | and /samples/xhtml2_subset.html | | Did you do the local-deploy step to deploy the | plugin? | | Do 'cd forrest-trunk; svn status to see what | you have changed. | | -David | | | -- | No virus found in this incoming message. | Checked by AVG Anti-Virus. | Version: 7.0.344 / Virus Database: 267.10.19/92 - Release Date: 7/09/2005 | | -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.19/92 - Release Date: 7/09/2005
Re: Blank page of xhtml2_subset.html
On Thu, 2005-09-08 at 20:10 +0800, Gav wrote: whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset_old.xml ? whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset.xml.mine ? whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset.xml.r279017 C whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src\documentation\content\xdocs\samples\xhtml2_subset.xml ? I think I might delete all the xhtml2_subset.* versions and do another svn up. yes. You have a confict! C whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src \documentation\content\xdocs\samples\xhtml2_subset.xml I imagine your whiteboard\plugins \org.apache.forrest.plugin.internal.xhtml2\src\documentation\content \xdocs\samples\xhtml2_subset.xml is not valid anymore. You will find things like mime ... do rm whiteboard\plugins\org.apache.forrest.plugin.internal.xhtml2\src \documentation\content\xdocs\samples\xhtml2_subset.* svn up That should solve your problem. HTH -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: xhtml2 tonights update questions
Tim Williams wrote: When you start reading these issues, it's not as bad as it sounds, I've got an xhtml page viewed at this point, although it's really ugly. Here's what I've done: o) Changed *.page to use a new pipeline **xhtmlbody-*.fhtml instead of the old **body-*.html o) Changed the stylesheet we got to deliver a div id=content wrapped html chunk instead of a complete html document. o) Added the **xhtmlbody-* pipeline mentioned above. It essentially just applies the stylesheet. o) Changed the **.html back to using *.page as it's generator src. o) Changed structurer.xmap to be pass-through. o) Tested each view-related pipeline with success. Here's why I haven't yet checked everything in (i.e. our problem) o) Having an internal plugin that matches **.html is really bad -- it breaks lots of stuff (e.g. menu-*.html, tab-*.html, etc.) o) As a workaround I changed the relevant bits to match and find *.fhtml instead of *.html. I did that because I wanted to see something working and it does. Bottom line (ok Thorsten get's one and only one i told you so';) appears to be that these won't work properly as an internal plugin. So, at this point I'm thinking the following course of action: 1) Create two brand new plugins o.a.f.p.internal.newCore o.a.f.p.output.defaultTheme don't worry so much about the names. The point is that we've (i've at least) learned tons by having this xhtml2 plugin but I think it's time already for a fresh start. We should make these new plugins with view/viewHelper as the model. What I'm calling newCore will obviously get rolled into the core forrest when we're done and the plugin removed. What I'm calling output.defaultTheme will likely go through name changes, may or may not be a part of core/stay in a plugin/etc. As i said in another thread, we might need to develop and throw away a few times, as we explore what is needed. Then we can get back up and running quicker so that we're not fighting with taking over core sitemap things like tab-*.html, etc, letting us focus on the real xhtml2 issue. There are other smaller problems too but this is the real showstopper at the moment. Thoughts? That sounds like a good approach to me. Even doing that *.fhtml thing is not such a workaround. The Cocoon sitemap gives us the power to do such internal pipelines. -David
[Summary][Vote] giving svn access to lenya commiters
Hello devs, I counted Positiv: 4 binding votes (+1) and 1 non-binding (+0) Negativ: 2 negative none veto votes (-0) which have been binding votes. That means we officially allow lenya committer to have write access to our code base. They are *not* voted in as committer. As well I want to take the opportunity for to make a statement. I did a senseless comment on the beginning of this vote that did not reflect the situation that we now have. I was talking about simple committership when calling the vote. That was not correct as *I* really see it. Yes http://apache.org/foundation/how-it-works.html#roles defines the role committer as follow: committer is a developer that was given write access to the code repository and has a signed Contributor License Agreement (CLA) on file. They have an apache.org mail address. Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. The PMC can (even tacitly) agree and approve it into permanency, or they can reject it. Remember that the PMC makes the decisions, not the individual people. The thing that I do not like on this description is that is missing one important (and IMO the most important) point expressed by David in another thread: On Sat, 2005-09-03 at 10:18 +1000, David Crossley wrote: We would not become committers at Lenya or Cocoon, just get svn access. To become committers proper we would go there, participate on their mailing lists, help users, be committed to the project, etc. I miss in above official description the point to *be* committed and what this actually mean. David pinpointed this very nice. To *be* committer in a project means that you participate on their mailing lists, help users, be committed to the project, etc. I repeated our discussion about simple committership vs PMC on the lenya dev list. Michis answer seems very interesting in the light of the above said. http://marc.theaimsgroup.com/?l=lenya-devm=112539704200829w=2 He actually is using the official definition of the ASF to fuel his argumentation. That has the certain background that Michi has a company where they use lenya for customer projects. Now his employees are sending tons of patches everyday and we do not have the time/resources to cope with all of them. The solution of simple committership seems logical. Now let us recall what David said, to *be* committer in a project means that you participate on their mailing lists, help users, be committed to the project, etc. The important point that I see in this is that David points out that the community building makes you a committer not so much the code contributions. This is as well my opinion. IMO we find a definition ASF wide to redefine the committer role. Clearly forrest committer are not automatically lenya committer and vice versa even if they meet the official ASF definition for this role. The situation we have now I see only as leveraging projects that have the same roots and were we can use synergy effects. Like stated by Ross it helps to just go ahead to apply your own patches on a foreign project where you have write access. I actually using this right @cocoon to fix typos and small things in their code base. The argument that I could create a patch and attach it to the issue tracker is not logically for me, because even if it takes me only 3 minutes, it will at least take another 3 Minutes for the cocoon committer that is applying my patch. Now simple math tells us that with 10 patches we spend 60 min on something that would normally take less then 10 min if I am doing directly. As soon as I have bigger changes I will create a diff and ask on the dev list to discuss this patch before applying it. I even do it sometimes on lenya and if I would change the forrest core I will do it here. I hope that I clarified my sloppy comment. salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
committer vs write access
At risk of keeping this going, I'll give my own thoughts on what you've said. I've moved this out of the vote thread too. As well I want to take the opportunity for to make a statement. I did a senseless comment on the beginning of this vote that did not reflect the situation that we now have. I was talking about simple committership when calling the vote. That was not correct as *I* really see it. Yes http://apache.org/foundation/how-it-works.html#roles defines the role committer as follow: committer is a developer that was given write access to the code repository and has a signed Contributor License Agreement (CLA) on file. They have an apache.org mail address. Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. The PMC can (even tacitly) agree and approve it into permanency, or they can reject it. Remember that the PMC makes the decisions, not the individual people. The thing that I do not like on this description is that is missing one important (and IMO the most important) point expressed by David in another thread: On Sat, 2005-09-03 at 10:18 +1000, David Crossley wrote: We would not become committers at Lenya or Cocoon, just get svn access. To become committers proper we would go there, participate on their mailing lists, help users, be committed to the project, etc. It is *not* missing that important point. In the definition, it says commiter += developer -- meaning to get the full definition, one needs to read them together. This is particularly important here because developer is where the definition expects those community aspects to happen. The definitions are rightfully based on meritorious progression in the roles. We're having this problem reconciling non-developers, non-contributers having write access to the code repository only because we're giving them write access without having earned it the way others do by progressing from user-dev-committer. I think the situation David is describing here lessen's significance of ASF Committership. I mean shucks, if I've got svn write access anyway, committer is just a title, not a role. They both can checkin code but neither has a binding vote. I've asked twice now what the *pragmatic* difference is between committer and one who has svn access. I miss in above official description the point to *be* committed and what this actually mean. David pinpointed this very nice. To *be* committer in a project means that you participate on their mailing lists, help users, be committed to the project, etc. see above I repeated our discussion about simple committership vs PMC on the lenya dev list. Michis answer seems very interesting in the light of the above said. http://marc.theaimsgroup.com/?l=lenya-devm=112539704200829w=2 I read this as why buy the cow, when you can get the milk for free. If we trust them with write access to the code repo, then we should trust their binding vote. Anything else is club-ish and subject I think. He actually is using the official definition of the ASF to fuel his argumentation. That has the certain background that Michi has a company where they use lenya for customer projects. Now his employees are sending tons of patches everyday and we do not have the time/resources to cope with all of them. The solution of simple committership seems logical. Now let us recall what David said, to *be* committer in a project means that you participate on their mailing lists, help users, be committed to the project, etc. The important point that I see in this is that David points out that the community building makes you a committer not so much the code contributions. This is as well my opinion. IMO we find a definition ASF wide to redefine the committer role. Clearly forrest committer are not automatically lenya committer and vice versa even if they meet the official ASF definition for this role. The situation we have now I see only as leveraging projects that have the same roots and were we can use synergy effects. Like stated by Ross it helps to just go ahead to apply your own patches on a foreign project where you have write access. Is there anyone that would really apply patches to a foreign project without being a developer in the true ASF sense of the word? I doubt it. Our situation is a little different and more akin to GSoC and could probably have been favorably solved in the same way Cocoon did their GSoC folks. I actually using this right @cocoon to fix typos and small things in their code base. The argument that I could create a patch and attach it to the issue tracker is not logically for me, because even if it takes me only 3 minutes, it will at least take another 3 Minutes for the cocoon committer that is applying my patch. Now simple math tells us that with 10 patches we spend 60 min on something that
[jira] Created: (FOR-669) pelt view project logo not aligned correctly
pelt view project logo not aligned correctly Key: FOR-669 URL: http://issues.apache.org/jira/browse/FOR-669 Project: Forrest Type: Bug Components: Views Versions: 0.8-dev Environment: Any Reporter: kevin Priority: Minor css bug in whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/skin/css/pelt/pelt.screen.css references to .grouplogo should be #grouplogo etc going to try and add a patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-669) pelt view project logo not aligned correctly
[ http://issues.apache.org/jira/browse/FOR-669?page=all ] kevin updated FOR-669: -- Attachment: pelt.screen.css.diff pelt view project logo not aligned correctly Key: FOR-669 URL: http://issues.apache.org/jira/browse/FOR-669 Project: Forrest Type: Bug Components: Views Versions: 0.8-dev Environment: Any Reporter: kevin Priority: Minor Attachments: pelt.screen.css.diff css bug in whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/skin/css/pelt/pelt.screen.css references to .grouplogo should be #grouplogo etc going to try and add a patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [FT] 2005-09-06 Summary
Gav wrote: Diwaker, great summary and gives us all an idea of what to do next and how to catch up. +1 - thanks for taking the time - this was *very* important. I also like cheches Interesting summary at: http://casa.che-che.com/~bot/forrest/ made me laugh. That is cool, I would like to highlight one of the random quotes as I feel it is particularly important for the community: addi49 matter of fact I'm a brewer In othr words, Addi is candidate number one to host our next get together (at least in my book - he brews good beer too). Cheche - thanks for getting Jenny to work so hard. Ross
Re: xhtml2 tonights update questions
Tim Williams wrote: When you start reading these issues, it's not as bad as it sounds, I've got an xhtml page viewed at this point, although it's really ugly. Great work Tim. [WARING] I have *not* looked at your work in detail, so my comments may be way off. If they are just say check the code and then get back to me, don't waste time explaining things in detail unless you see the need. The reason I'm jumping in now is I am really busy for a week or so and may not be able to look at your code in detail, I just have a *major* concern that I want to air early in order to avoid too much effort in the wrong direction. Here's what I've done: o) Changed *.page to use a new pipeline **xhtmlbody-*.fhtml instead of the old **body-*.html Views should not use aggregation of body, site, tabs etc. Each of these parts are just nuggets of data that should be pulled together as and when they are required. That is if I want navigation I should have a nav contract that knows where to find the content. Look at the content-include-html contract [1] as an example of how to do this. For further discussion see Step 3: Filtering in our TR [2] Why do it this way. Well one reason is that it solves the problems you highlight below. The other is that it removes an inneficiency in the current system. That is, if I request a document that does not have navigation (e.g. a PDF rendering of a page) then the whole aggregation step is a waste of time. Striping this one step from the PDF output alone will improve Forrest performance a great deal. Another reason is that it makes a much tidier sitemap and it separates the concerns of content aggregation (structurer) and content processing (sitemap). Here's why I haven't yet checked everything in (i.e. our problem) o) Having an internal plugin that matches **.html is really bad -- it breaks lots of stuff (e.g. menu-*.html, tab-*.html, etc.) That problem will go away with the above approach ;-) o) As a workaround I changed the relevant bits to match and find *.fhtml instead of *.html. I did that because I wanted to see something working and it does. That need will go away with the above approach ;-) Bottom line (ok Thorsten get's one and only one i told you so';) appears to be that these won't work properly as an internal plugin. Yes it will ;-) So, at this point I'm thinking the following course of action: 1) Create two brand new plugins o.a.f.p.internal.newCore o.a.f.p.output.defaultTheme don't worry so much about the names. The point is that we've (i've at least) learned tons by having this xhtml2 plugin but I think it's time already for a fresh start. I'm all for a fresh start, but lets explore the above first. I believe it will greatly simplify the overall forrest pipeline and, more importantly, bring us into line with out TR since the filtering of content will be contained in the structurer only, rather than split across core and views. We should make these new plugins with view/viewHelper as the model. What I'm calling newCore will obviously get rolled into the core forrest when we're done and the plugin removed. What I'm calling output.defaultTheme will likely go through name changes, may or may not be a part of core/stay in a plugin/etc. As we discussed on IRC, there are things in the current XHTML2 plugin that should be in a theme plugin, so I agree there is a need. But not for the reason you highlight above. Then we can get back up and running quicker so that we're not fighting with taking over core sitemap things like tab-*.html, etc, letting us focus on the real xhtml2 issue. Interestingly enough *.page is the only matcher I have not added to structurer.xmap, for the reasons above. My commit messages did not highligh this, sorry. WDYT? [1] http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/content-include-html.ft [2] http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs/TR/2004/WD-forrest10.html
Re: xhtml2 tonights update questions
I'll read the rest of this later but really quickly I don't see how moving the navi stuff out to a contract (which I agree with btw) is going to solve my problem. It's not going to change that the internal plugin xmap has match precedence over the menu.xmap. I've been thinking we were taking baby steps here. I don't know that I want to tackle both xhtml2 to core and views refinement at the same time. My goal has just been to get the former done with current views, then tackle views refinement armed with what was learned in the first step. I think it'll take going through the pain of the first step in order for everyone to be able to speak intelligently about views and what the implications of suggestioning certain conceptual refinements might be technically. For example, in this process so far, I've been notetaking my own ideas of how we might improve views but I don't want that to slow down the xhtml2 to core progress -- as it will require lots of non-code-but-thinking discussion. --tim On 9/8/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: When you start reading these issues, it's not as bad as it sounds, I've got an xhtml page viewed at this point, although it's really ugly. Great work Tim. [WARING] I have *not* looked at your work in detail, so my comments may be way off. If they are just say check the code and then get back to me, don't waste time explaining things in detail unless you see the need. The reason I'm jumping in now is I am really busy for a week or so and may not be able to look at your code in detail, I just have a *major* concern that I want to air early in order to avoid too much effort in the wrong direction. Here's what I've done: o) Changed *.page to use a new pipeline **xhtmlbody-*.fhtml instead of the old **body-*.html Views should not use aggregation of body, site, tabs etc. Each of these parts are just nuggets of data that should be pulled together as and when they are required. That is if I want navigation I should have a nav contract that knows where to find the content. Look at the content-include-html contract [1] as an example of how to do this. For further discussion see Step 3: Filtering in our TR [2] Why do it this way. Well one reason is that it solves the problems you highlight below. The other is that it removes an inneficiency in the current system. That is, if I request a document that does not have navigation (e.g. a PDF rendering of a page) then the whole aggregation step is a waste of time. Striping this one step from the PDF output alone will improve Forrest performance a great deal. Another reason is that it makes a much tidier sitemap and it separates the concerns of content aggregation (structurer) and content processing (sitemap). Here's why I haven't yet checked everything in (i.e. our problem) o) Having an internal plugin that matches **.html is really bad -- it breaks lots of stuff (e.g. menu-*.html, tab-*.html, etc.) That problem will go away with the above approach ;-) o) As a workaround I changed the relevant bits to match and find *.fhtml instead of *.html. I did that because I wanted to see something working and it does. That need will go away with the above approach ;-) Bottom line (ok Thorsten get's one and only one i told you so';) appears to be that these won't work properly as an internal plugin. Yes it will ;-) So, at this point I'm thinking the following course of action: 1) Create two brand new plugins o.a.f.p.internal.newCore o.a.f.p.output.defaultTheme don't worry so much about the names. The point is that we've (i've at least) learned tons by having this xhtml2 plugin but I think it's time already for a fresh start. I'm all for a fresh start, but lets explore the above first. I believe it will greatly simplify the overall forrest pipeline and, more importantly, bring us into line with out TR since the filtering of content will be contained in the structurer only, rather than split across core and views. We should make these new plugins with view/viewHelper as the model. What I'm calling newCore will obviously get rolled into the core forrest when we're done and the plugin removed. What I'm calling output.defaultTheme will likely go through name changes, may or may not be a part of core/stay in a plugin/etc. As we discussed on IRC, there are things in the current XHTML2 plugin that should be in a theme plugin, so I agree there is a need. But not for the reason you highlight above. Then we can get back up and running quicker so that we're not fighting with taking over core sitemap things like tab-*.html, etc, letting us focus on the real xhtml2 issue. Interestingly enough *.page is the only matcher I have not added to structurer.xmap, for the reasons above. My commit messages did not highligh this, sorry. WDYT? [1]
Re: xhtml2 tonights update questions
Tim Williams wrote: I'll read the rest of this later but really quickly I don't see how moving the navi stuff out to a contract (which I agree with btw) is going to solve my problem. It's not going to change that the internal plugin xmap has match precedence over the menu.xmap. I'm not sure exactly what the problem is here. Yo9u only refer to problems with *.html matches. However, I don't think I need to understand the problem because the internal plugin is intended to be a complete rewrite of core (see the start of the IRC logs from where Nickola logged in). In this plugin we will be replacing *all* matches in core. i.e. add a ew menu.xmap to the plugin. I've been thinking we were taking baby steps here. I don't know that I want to tackle both xhtml2 to core and views refinement at the same time. I don't think we can separate them efficiently, but I'm still reading... My goal has just been to get the former done with current views, then tackle views refinement armed with what was learned in the first step. Hmmm... I think it'll take going through the pain of the first step in order for everyone to be able to speak intelligently about views and what the implications of suggestioning certain conceptual refinements might be technically. There is some value in what you say here. However, I hate doing the same job twice and always like to avoid doing so. In other words, if it is not going to increase the workload then I say go for it. I only raised the issue because your mail made me think that you perhaps hadn't understood what the TR meant and the direction we are heading as a project (you being fairly new around here and all that). For example, in this process so far, I've been notetaking my own ideas of how we might improve views but I don't want that to slow down the xhtml2 to core progress -- as it will require lots of non-code-but-thinking discussion. By all means, proceed with your direction. We (the community) will continue to make you aware of where we think we need to go in the future. Your new eyes on the core code can only serve to add value to those ideas. My mails are meant to be informative/discussive, they do *not* contain instructions ;-) Ross
Re: [FT] 2005-09-06 Summary
On Thursday September 08 2005 5:15 pm, Ross Gardler wrote: I also like cheches Interesting summary at: http://casa.che-che.com/~bot/forrest/ made me laugh. That is cool, I would like to highlight one of the random quotes as I feel it is particularly important for the community: addi 49 matter of fact I'm a brewer In othr words, Addi is candidate number one to host our next get together (at least in my book - he brews good beer too). LOL, well if ApacheCon comes to Washington, DC you're all welcome to my place. But I should warn you, so you're not shocked if you meet me, I'm actually a she. :) Cheche - thanks for getting Jenny to work so hard. Ross
Re: forrest:views and xhtml2
On 9/8/05, Thorsten Scherler [EMAIL PROTECTED] wrote: Hi all, why are we using views in the xhtml2 plugin? This seems like an odd question. Because views are an integral part of the TR? The plugin has turned into a next-gen forrest complete w/ new internal structure, refined views, integral locationmap usage, and streamlined sitemap. Why do you ask? --tim
Re: xhtml2 tonights update questions
On 9/8/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: I'll read the rest of this later but really quickly I don't see how moving the navi stuff out to a contract (which I agree with btw) is going to solve my problem. It's not going to change that the internal plugin xmap has match precedence over the menu.xmap. I'm not sure exactly what the problem is here. Yo9u only refer to problems with *.html matches. However, I don't think I need to understand the problem because the internal plugin is intended to be a complete rewrite of core (see the start of the IRC logs from where Nickola logged in). In this plugin we will be replacing *all* matches in core. i.e. add a ew menu.xmap to the plugin. This i.e. is key;) It's taken me some time to realize the scope of what we're trying to accomplish with this plugin. As much talk as we had around it - I don't know if everyone fully considered the scope of what we are under-taking here. Since the plugin and forrest tuesday were titled xhtml2 in the core I never thought much about the extra stuff (e.g. view refinement, etc.) -- even though, as you point out, it was written down like that. I've been thinking we were taking baby steps here. I don't know that I want to tackle both xhtml2 to core and views refinement at the same time. I don't think we can separate them efficiently, but I'm still reading... My goal has just been to get the former done with current views, then tackle views refinement armed with what was learned in the first step. Hmmm... I think it'll take going through the pain of the first step in order for everyone to be able to speak intelligently about views and what the implications of suggestioning certain conceptual refinements might be technically. There is some value in what you say here. However, I hate doing the same job twice and always like to avoid doing so. In other words, if it is not going to increase the workload then I say go for it. I only raised the issue because your mail made me think that you perhaps hadn't understood what the TR meant and the direction we are heading as a project (you being fairly new around here and all that). I think I grasped the TR. I didn't grasp that the scope of the current effort was implementing the entire TR. I thought we were only focused on the first part -- using XTHML2 as our source. I just didn't pick up on that earlier for some reason. For example, in this process so far, I've been notetaking my own ideas of how we might improve views but I don't want that to slow down the xhtml2 to core progress -- as it will require lots of non-code-but-thinking discussion. By all means, proceed with your direction. We (the community) will continue to make you aware of where we think we need to go in the future. Your new eyes on the core code can only serve to add value to those ideas. ok, i assume that someone will revert when I go astray;) My mails are meant to be informative/discussive, they do *not* contain instructions ;-) Yeah, this part I understood;) --tim
[jira] Commented: (FOR-655) Create sample document for XHTML2 subset
[ http://issues.apache.org/jira/browse/FOR-655?page=comments#action_12322986 ] David Crossley commented on FOR-655: The xhtml2 document has been added to the new experimental plugin: whiteboard/plugins/org.apache.forrest.plugin.internal.xhtml2 as xhtml2_subset.xml (There is also another xhtml2 example at index.xml). So if you have changes, then please provide a patch to those. The basic html pipeline in that plugin is now presenting an html rendition of those source docs, so you don't need the static html version anymore. Create sample document for XHTML2 subset Key: FOR-655 URL: http://issues.apache.org/jira/browse/FOR-655 Project: Forrest Type: Sub-task Versions: 0.8-dev Reporter: Ross Gardler Fix For: 0.8-dev Define the set of XHTML2 modules that will be used and document those by example. See discussion in thread: Re: XHTML2 - let's do it! http://marc.theaimsgroup.com/?t=11248949717 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [FT] 2005-09-06 Summary
addi wrote: Ross Gardler wrote: I also like cheches Interesting summary at: http://casa.che-che.com/~bot/forrest/ made me laugh. That is cool, I would like to highlight one of the random quotes as I feel it is particularly important for the community: addi 49 matter of fact I'm a brewer In othr words, Addi is candidate number one to host our next get together (at least in my book - he brews good beer too). LOL, well if ApacheCon comes to Washington, DC you're all welcome to my place. Can you bring a supply to the upcoming ApacheCon in San Diego? :-) That is only partially a joke. At least Ferdinand is going to be there, maybe more of us. It would be great to have other Forrest developers and users. But I should warn you, so you're not shocked if you meet me, I'm actually a she. :) You could have saved that shock and gained a great laugh when we did meet you. Still i laugh now. Isn't it strange how we assume an online person to be male. I can see why. Historically, most of the particpants in opensource projects are male. Still that is no excuse to assume. Names are safer. I know that people need another mailing list like a hole in the head, but we have a new list http://mail-archives.apache.org/mod_mbox/www-women/ which was formed to talk about why there are not more females involved in opensource and how to address that situation at Apache. Even though ASF projects are nice communities, and i find Apache Forrest to be especially so, we want to make them even more welcoming. -David
Re: xhtml2 tonights update questions
On 9/8/05, David Crossley [EMAIL PROTECTED] wrote: Tim Williams wrote: I think I grasped the TR. I didn't grasp that the scope of the current effort was implementing the entire TR. I thought we were only focused on the first part -- using XTHML2 as our source. I just didn't pick up on that earlier for some reason. We are focussing on the first part, but that also involves all the rest because we need new core pipelines. -David Technically, these are two separate issues. I'm cool with it either way but I just want to make note about what we really *need* to do vs. what we're making a concious choice to do. In order to use XHTML2 with views (or for the existing skins for that matter) we need a transform (e.g. document2html) and a mod to the *.page pipeline that calls that transform instead of the existing **body-*.html pipe (w/ some other small tweaks here and there). This new stylesheet and the new pipe would still be re-used even in our new concept of views -- so it wouldn't be throw-away as far as I can tell. I'm still catching up on Thorsten's long email the other day about views, dispatcher, etc so I'm not sure what the implication is quite yet, but he's now thinking java for some and jxtemplates for the structurer. So, views is also somewhat of a moving target. That being the case, it's probably important that we explicitly recognize that this will be the location for future view development from now on vs. view/viewHelper. If we *want* to take it all on now, that's fine, I just didn't get that for some reason. --tim
Re: [FT] 2005-09-06 Summary
Can you bring a supply to the upcoming ApacheCon in San Diego? :-) That is only partially a joke. At least Ferdinand is going to be there, maybe more of us. It would be great to have other Forrest developers and users. I live in San Diego :-) So I'm definitely going to be there (modulo certain unexpected events in my calendar). -- Web/Blog/Gallery: floatingsun.net
