pdf-link and txt-link in views
Hi Thorsten and list,
Has anyone got pdf-link and txt-link contracts working in views? I
tried them out today. The pdf-link contract doesn't even run -- I get
the following exception:
X [0] linkmap.html BROKEN:
javax.xml.transform.TransformerException: ElemTemplateElement error:
pdf-link-body
With the txt-link, the build goes fine, but the txt pages are just
never generated. Also, the txt-link target just generates a whole
bunch of Javascript in the generated page:
div id=export-linkscript language=Javascript type=text/javascript
#9;function printit() {
#9; if (window.print) {
#9;window.focus();
#9;window.print();
#9; }
#9;}
#9;/scriptscript language=Javascript type=text/javascript
#9;var NS = (navigator.appName == Netscape);
#9;var VERSION = parseInt(navigator.appVersion);
#9;if (VERSION gt; 3) {
#9; document.write('div title=Print this Page class=txt');
#9; document.write(' a class=dida href=javascript:printit()');
#9; document.write('img alt=print - icon
src=skin/images/printer.gif class=skin /');
#9; document.write('br /');
#9; document.write(' PRINT/a');
#9; document.write('/div');
#9;}
#9;/script
I'm still looking into it.
Also, I would recommend changing the div tag for notes and warning
from frame note to frame-note for example. I just don't like the
space because its inconvinient when writing CSS rules. The change is
trivial:
Index: main/webapp/skins/common/xslt/html/document2html.xsl
===
--- main/webapp/skins/common/xslt/html/document2html.xsl
(revision 180076)
+++ main/webapp/skins/common/xslt/html/document2html.xsl(working copy)
@@ -137,7 +137,7 @@
xsl:template match=note | warning | fixme
xsl:apply-templates select=@id/
-div class=frame {local-name()}
+div class=frame-{local-name()}
div class=label
xsl:choose
!-- FIXME: i18n Transformer here --
cheers,
Diwaker
--
Diwaker Gupta
http://resolute.ucsd.edu/diwaker
Re: Add support for Googles sitemap protocol?
The only requried information in the sitemap is the URL. This means we can create the Google sitemap now, with minimal effort. Over time we can enhance this by adding further meta-data once it becomes available. I'm happy to go for the Google format, I just thought that our commitment to standards would tip the balance towards OAI. Does OAI not allow for a minimal form like Googles'? If we go for the Google format, I'd like to suggest to use slightly more than the minimum format in this form (as documented in https://www.google.com/webmasters/sitemaps/docs/en/protocol.html) ?xml version=1.0 encoding=UTF-8? urlset xmlns=http://www.google.com/schemas/sitemap/0.84; url lochttp://www.yoursite.com/catalog?item=83amp;desc=vacation_usa/loc lastmod2004-11-23/lastmod /url /urlset and include the 'lastmod' right away as that would be the key to speedy updates. Can we do that? Did you see that Google wants the urls to be url encoded? Does our XSLT-engine have a function for that? -- Ferdinand Soethe
[Proposal] reply-to: forrest-dev
Hello devs, I propose to set the reply-to header of this mailing list to forrest-dev by default. How can I do that (as moderator) and should I call a vote before doing it? salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: [RT] Why using views - in comparison with old fashion skins - usecase i18n.
On Sat, 2005-06-04 at 21:03 -0700, Diwaker Gupta wrote: Yes that would be great. :) That could be the 'last-published-net' contract. Its funny, I chose the *exact* same name even before I wrote my first mail :) lol :) Yeah, once started working with views and contracts the naming for the contracts is pretty straight forward I guess. :) ;-) Anyways, I'm attaching last-published-net.ft. It uses an improved version of the XSL date service (no Perl script!). :) very nice. I just copied the contract in my local development project (for testing) and it works like a charm. :) Thx a million. I will check that now in (in the viewHelper.xhtml) with a small change in the caption instead of Last published on xsl:value-of select=$dt/ I will checkin i18n:text Last Published:/i18n:text#160; xsl:value-of select=$dt/ Now were we set up the i18n support we should use it. ;-) I added as well a blank.ft which can serve as copy'n paste master in the beginning for your offline editor and later on for the cform-based view/contract online-editor-plugin I will add (hopefully) soon. BTW if you want to submit another contract that will get rid of jscript, try sending a patch for http://issues.apache.org/jira/browse/FOR-134 Right now that do not exists as a contract, but I would like to see the breadcrumbs.ft solving FOR-134 and not implementing the old code. ;-) ...after wards it easy to back port that to old fashion skins. In addition, if a network connection is not available, one can use a similar solution on the localhost -- I have written a simple Python script to generate the required XML, so just replace the URL in the document function call with the path to date.py :) For now I did not check that script in but if you could write some words how to setup everything and provide a 'last-published-local-net' contract I will do that ASAP. My problem is where to add the *.py. IMO that is a businessService and I still have to still look into the locationmap branch where I guess businessServices should be defined. BTW the commits and mails relating to that topic are *very* promising. @Ross how are the changes that we can use the locationmap stuff in a plugin (businessHelper-plugin). ;-) I had a related question: it seems wasteful to generate the timestamp again and again for each processed file. Since the build happens within a few minutes at most, I'm content with recording the time at the start of the build and then using that throughout. This will save a lot of CPU cycles. I'm not an expert at XSL so I'm still looking as to what is the best way to define such a global timestamp variable. Yeah +1 Any suggestions how to implement that? Maybe with the locationmap? Thank you very much, Diwaker, for your constant testing effort, feedback and patches for views that is helping me a million. Keep on! :) salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: [jira] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
On Sat, 2005-06-04 at 23:03 -0400, Pedro I. Sanchez wrote:
On Sun, 2005-05-06 at 04:19 +0200, Thorsten Scherler wrote:
On Sat, 2005-06-04 at 20:55 -0400, Pedro I. Sanchez wrote:
snip/
My version of the Spanish messages would be the following:
catalogue
message key=Font size:Tamaño del texto:/message
message key=Last Published:Fecha de publicación:/message
message key=SearchBuscar/message
message key=Search the site withBuscar en/message
/catalogue
Nice, can you prepare a patch and add it to this issue? I will apply it
then, thx. I reckon there are more to come. ;-)
Index: webapp/skins/common/messages/CommonMessages_es.xml
===
--- webapp/skins/common/messages/CommonMessages_es.xml (revision
180032)
+++ webapp/skins/common/messages/CommonMessages_es.xml (working copy)
@@ -15,8 +15,9 @@
limitations under the License.
--
catalogue
- message key=Font size:Tamaño de fuente:/message
- message key=Last Published:Último publicado:/message
- message key=SearchBúsqueda/message
- message key=Search the site withBúsqueda en/message
+ message key=Font size:Tamaño del texto:/message
+ message key=Last Published:Fecha de publicación:/message
+ message key=SearchBuscar/message
+ message key=Search the site withBuscar en/message
/catalogue
+
Patch applied to trunk.
Now, how do i specify the desired language? The i18n doc talks about
specifying the locale in the transform, I guess in a map file. Ideally
it should be specified forrest.properties, or even better at the command
line, like:
$ LANG=de_DE forrest
How is it done now?
Actually I just tested it in 'forrest run' and not forrest.
In the dynamic mode you can change the preferred language of your
browser and hit refresh.
In my experience, relying on the end user to select a language in his
browser is never a good option. Most people don't even know they can do
it. And you don't want your web pages to have to explain how to change
the language option so that the pages can be read in a different
language.
Yeah you are right I guess we need some pics or a form to change the
locals via the site. Patches welcome. ;-) I will have a look later.
In my case, my short-time interest is to generate a site that will show
up in Spanish only, and this regardless of the language option of the
web browser. In real life most web sites are written in a single
language and they show up as such regardless of the language settings in
the web browsers.
Right now you find in the main forrest sitemap.xmap:
map:transform type=i18n
map:parameter name=locale value={request:locale}/
/map:transform
The question is how to parse the request:locale to the cli? ATM I do not
know that, but I guess that is possible. ;-)
This is key for me. If I cannot specify the language when I run
forrest to build my site then this is not a good solution. I guess the
other option would be to hard-code value=es_ES in the above. At least
this would be just one thing hard coded :|
Yeah that would solve your usecase, but in the future that should be
done like you suggested in your former mail.
LANG=de_DE forrest
Any thoughts, how?
One other comment: You are placing the catalogues under common/messages,
which is probably fine for the default skin. But I believe that skins
should come with their own catalogues because each can have an entirely
different set of labels to be translated. Is this being accommodated by
the skins plugin thing?
Yes, this will go into views for now I added it to viewHelper.xhtml.
There are some points I found out for a full i18n support for skins
(view based). ...but this will be another thread. ;-)
I reckon you have to extend the catalogues section like the following,
but I have not test that.
catalogues default=common
catalogue id=common name=CommonMessages
location=skins/common/messages/
catalogue id={forrest:skin} name={forrest:skin}Messages
location=skins/{forrest:skin}/messages/
/catalogues
Yes, I was thinking along these lines. Each skin has to have its own
catalogue as an extension of a common catalogue that all skins can use.
But I read something about a skins plugin in development and I was
wondering how this plugin would automatically update this index of
catalogues.
Actually that needs discussion. Right now the catalogues are in
forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/messages/
I am not sure what would be the best to automatically update this index
of catalogues and whether this should be done by the plugin. For now we
just add all messages of the contract there.
...but you are right we have to think how to mount as well
project-specific catalogues.
Any thoughts, how?
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink
Re: pdf-link and txt-link in views
On Sun, 2005-06-05 at 02:16 -0700, Diwaker Gupta wrote:
Hi Thorsten and list,
Has anyone got pdf-link and txt-link contracts working in views? I
tried them out today. The pdf-link contract doesn't even run -- I get
the following exception:
X [0] linkmap.html BROKEN:
javax.xml.transform.TransformerException: ElemTemplateElement error:
pdf-link-body
Did you add org.apache.forrest.plugin.output.pdf to required plugins?
...but yeah this contracts are buggy. I will re-factor that code ASAP
(will go now out for lunch). ;-)
The pdf-link within the content-contract is working, but I am in the
middle of refactoring this contract to better extract the features added
by the document2html.xsl. This link and the other are on my list. ;-)
With the txt-link, the build goes fine, but the txt pages are just
never generated. Also, the txt-link target just generates a whole
bunch of Javascript in the generated page:
div id=export-linkscript language=Javascript
type=text/javascript
#9;function printit() {
#9; if (window.print) {
#9;window.focus();
#9;window.print();
#9; }
#9;}
#9;/scriptscript language=Javascript
type=text/javascript
#9;var NS = (navigator.appName == Netscape);
#9;var VERSION = parseInt(navigator.appVersion);
#9;if (VERSION gt; 3) {
#9; document.write('div title=Print this Page class=txt');
#9; document.write(' a class=dida
href=javascript:printit()');
#9; document.write('img alt=print - icon
src=skin/images/printer.gif class=skin /');
#9; document.write('br /');
#9; document.write(' PRINT/a');
#9; document.write('/div');
#9;}
#9;/script
I'm still looking into it.
Yeah I will re-factor that ASAP. It is direct copy of pelt. ;-)
Also, I would recommend changing the div tag for notes and warning
from frame note to frame-note for example. I just don't like the
space because its inconvinient when writing CSS rules. The change is
trivial:
Index: main/webapp/skins/common/xslt/html/document2html.xsl
===
--- main/webapp/skins/common/xslt/html/document2html.xsl
(revision 180076)
+++ main/webapp/skins/common/xslt/html/document2html.xsl
(working copy)
@@ -137,7 +137,7 @@
xsl:template match=note | warning | fixme
xsl:apply-templates select=@id/
-div class=frame {local-name()}
+div class=frame-{local-name()}
div class=label
xsl:choose
!-- FIXME: i18n Transformer here --
I will look on that. Have to go now.
cheers,
Diwaker
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: Add support for Googles sitemap protocol?
Ferdinand Soethe wrote: The only requried information in the sitemap is the URL. This means we can create the Google sitemap now, with minimal effort. Over time we can enhance this by adding further meta-data once it becomes available. I'm happy to go for the Google format, I just thought that our commitment to standards would tip the balance towards OAI. Does OAI not allow for a minimal form like Googles'? Good point. However, I don't think OAI has a minimal form, I did some preliminary research into it a few months ago. Let me check it out, I'll report back. However, I'd still like to see support for Google sitemaps since we can do it very quickly and it is more approachable than OAI since everyone knows Google. If we go for the Google format, I'd like to suggest to use slightly more than the minimum format in this form (as documented in https://www.google.com/webmasters/sitemaps/docs/en/protocol.html) ?xml version=1.0 encoding=UTF-8? urlset xmlns=http://www.google.com/schemas/sitemap/0.84; url lochttp://www.yoursite.com/catalog?item=83amp;desc=vacation_usa/loc lastmod2004-11-23/lastmod /url /urlset and include the 'lastmod' right away as that would be the key to speedy updates. Can we do that? No. At least at present, unless you experiments with the cache-key thingy show otherwise. At present all files are rebuilt regardless of whether they have changed. The need for keeping track of last modified files is something that comes up fairly regularly. We all want it, but nowone has had a sufficient itch yet. I'd recomend getting the minimal done, then looking at a way of getting the lastmod as well. I'd like to see us being able to create meta-data with last-mod, likely change frequency etc. the itch is getting stronger, but it is not stong enough (for me personally) just yet. Did you see that Google wants the urls to be url encoded? Does our XSLT-engine have a function for that? http://www.exslt.org/str/functions/encode-uri/index.html NOTE the code on the above side is in the public domain we *cannot* relicense it as ASF, so the best thing to do is to write our own version of the function using replace(string,pattern,replace), the above is useful for quick testing, but please don't commit it to our CVS. The replace function returns a string that is created by replacing the given pattern with the replace argument Example: replace(Bella Italia, l, *) Result: 'Be**a Ita*ia' Example: replace(Bella Italia, l, ) Result: 'Bea Itaia' Ross
Re: [jira] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
Pedro I. Sanchez wrote: On Sun, 2005-05-06 at 04:19 +0200, Thorsten Scherler wrote: On Sat, 2005-06-04 at 20:55 -0400, Pedro I. Sanchez wrote: ... Nice, can you prepare a patch and add it to this issue? I will apply it then, thx. I reckon there are more to come. ;-) Index: webapp/skins/common/messages/CommonMessages_es.xml Pedro, thanks for your patch. Just a point to note, in future it is best to attach a patch to a related issue, that way it doesn't get lost in the archives. In this case Thorsten is on the ball so it doesn't matter, but imagine he had been called away for work. An email is easy to forget about, a patch isn't. Once again, thanks for highlighting this need, and for your contribution. Ross
Re: [Proposal] reply-to: forrest-dev
Thorsten Scherler wrote: Hello devs, I propose to set the reply-to header of this mailing list to forrest-dev by default. How can I do that (as moderator) and should I call a vote before doing it? I have no problem with this since we already reply to [EMAIL PROTECTED] as far as I am concerned this doesn't need a vote, but in case it does you have my +1 Ross
Re: Add support for Googles sitemap protocol?
Ross Gardler wrote: Ferdinand Soethe wrote: The only requried information in the sitemap is the URL. This means we can create the Google sitemap now, with minimal effort. Over time we can enhance this by adding further meta-data once it becomes available. I'm happy to go for the Google format, I just thought that our commitment to standards would tip the balance towards OAI. Does OAI not allow for a minimal form like Googles'? Good point. However, I don't think OAI has a minimal form, I did some preliminary research into it a few months ago. Let me check it out, I'll report back. OK, I've rechecked the schema and the OAI-PMH schema requires that a date be provided in headers for each record (which coresponds to a documet in our case). This means we need the last modified date otherwise our data will be inaccurate, that is using last-published will make harvesters think that the file was modified on that date. see http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm#OAIPMHschema Furthermore, as I mentioned in a previous mail, OAI is not about indexing documents (like the Google sitemap) it is about indexing meta-data. To use OAI-PMH for anything worthwdile requires quite a bit of additional functionality like complete meta-data etc. I *do* want to see this included but do not believe it is appropriate to the vast majority of our present users. I think we should proceed with the simpler case of Google and return to OAI wen we have a meta-data system in place. Ross
Re: [RT] Why using views - in comparison with old fashion skins - usecase i18n.
Thorsten Scherler wrote: hello devs, I just work on the i18n integration for pelt and crossed again the whys for using views. ;-) This mail makes for a pretty good piece of documentation. A number of times over the last couple of weeks I have wanted to write a mail asking you to write some user level documentation for views. You see, I keep finding a few minutes to play with new stuff and Views is one of the things I keep starting up and looking at. However, I never get past looking at it. The reason is that I am thoroughly confused by the huge amount of RT's that have been posted on this subject. It currently seems to me that views are the solution to eveything. This makes it really difficult for me to get started. So I was going to ask you to write a simple How-To on creating a new contract, and then embedding it in my own site. As I say, I have resisted asking you to do this because I know I have very little time for views until 0.7 is released, all my none payed for time is currently spent on the 0.7 release. However, this RT is *almost* the how to I want to see so perhaps I should be brave enough to ask. Is there any chance you can move the *user* relevant parts into a How-To for views? It doesn't matter if it is not complete, just something that will enable poor old me to get past the confusion of views does everything to views does this nice simple task like this. Maybe my poor little brain can catch up with you then :-) Thanks, Ross
Re: does checksums-uri in cli.conf work?
Trying to test the checksums-uri in cli.conf, I got really confused
and I'm not sure what is happening. Did I miss something or are there
indeed several nonfunctional settings in cli.conf?
I'd appreciate some comments on this.
Regards,
Ferdinand Soethe
Here is what I did
1. Seeded a new forrest site in mysite
2. Create new dir
3. Copied P:\forrest\main\webapp\WEB-INF\cli.xconf to mysite
4. Added new line
project.configfile=${project.home}/src/documentation/conf/cli.xconf
below
#project.translations-dir=${project.content-dir}/translations
5. Added the setting
checksums-uri../checksums/checksums-uri
below the commented section.
6. Did a 'forrest site'
Now I should have found a new directory build/checksums.
But I did't.
I checked the rest of the forrest tree. No difference.
7. To be sure I created the directory and did a 'forrest site' once
again.
Nothing changed. New dir remained empty.
8. No I changed the setting (to be sure mir cli.xconf was processed)
dest-dir../site/dest-dir
to
dest-dir../sitetest/dest-dir
9. Deleted build and did a 'forrest site'
Output was still written to build/site.
10. Finally I added
exclude pattern=**/*.html/
and found that no more html-page where written to site.
My Conclusion:
I had modified the correct cli.conf.
The exclude pattern is recognized.
The other options are not processed.
Re: Locationmap now works for repositories
After reading, studying *.xmap, and re-reading, I think I'm understanding this a bit better. My question is should the locationmap match be moved earlier in the pipeline? I got the behaviour I would have expected by moving it immediately before all of the i18n matches for regular source content. --tim On 6/4/05, Tim Williams [EMAIL PROTECTED] wrote: Thanks Ross this is great stuff. It seems that locationmap'ed content is a secondary priority in terms of retrieving content. For a real world scenario it likely won't matter but for folks testing this out like me, if there's matching content in the xdocs it seems that it is retrieved first, then if it doesn't exist, the locationmap matches are used. --tim On 6/4/05, Ross Gardler [EMAIL PROTECTED] wrote: Well Zeph, my son, had a nightmare so I'm wide awake in the middle of the night (again), as a result I spent some time on the Locationmap branch. The good news is that it now works for generating files from a repository. I've created a demo within fresh-site (in the locationmap branch). The demo shows how to do link rewriting and how to retrieve content from a remote repository without having to encode the location of the repository or the path to the file within it in the Forrest site URL. This is pretty powerful stuff. It means we can create single sites from multiple repositories, whether they be local, remote or a combination of the two. Next stage is for me to make the Daisy plugin work with the locationmap. I can't remember who wrote the locationmap code it was so long ago. I wish I had had the itch to play with it a long time ago. In my opinion this is going to be another key feature of Forrest. The future of Forrest looks bright: - Plugins - Views - Locationmaps this is killer stuff! Ross
Re: [RT] Why using views - in comparison with old fashion skins - usecase i18n.
On Sun, 2005-06-05 at 14:37 +0100, Ross Gardler wrote: Thorsten Scherler wrote: hello devs, I just work on the i18n integration for pelt and crossed again the whys for using views. ;-) This mail makes for a pretty good piece of documentation. :) It explains a wee bit better what I am doing to create the contracts. ;-) A number of times over the last couple of weeks I have wanted to write a mail asking you to write some user level documentation for views. You see, I keep finding a few minutes to play with new stuff and Views is one of the things I keep starting up and looking at. However, I never get past looking at it. The reason is that I am thoroughly confused by the huge amount of RT's that have been posted on this subject. It currently seems to me that views are the solution to eveything. This makes it really difficult for me to get started. So I was going to ask you to write a simple How-To on creating a new contract, and then embedding it in my own site. Yeah I can understand that. Did you see whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/src/documentation/content/xdocs/index.xml I will extend that with this RT and write a howto. As I say, I have resisted asking you to do this because I know I have very little time for views until 0.7 is released, all my none payed for time is currently spent on the 0.7 release. However, this RT is *almost* the how to I want to see so perhaps I should be brave enough to ask. :) Is there any chance you can move the *user* relevant parts into a How-To for views? It doesn't matter if it is not complete, just something that will enable poor old me to get past the confusion of views does everything to views does this nice simple task like this. Yeah I will extend as well the part of using basic forrest:views for writing view configs. Maybe my poor little brain can catch up with you then :-) I need as well to write some slides for the upcoming workshop about views. How did you do it again within forrest. ;-) Thanks, Ross salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Locationmap now works for repositories
Tim Williams wrote: After reading, studying *.xmap, and re-reading, I think I'm understanding this a bit better. My question is should the locationmap match be moved earlier in the pipeline? I got the behaviour I would have expected by moving it immediately before all of the i18n matches for regular source content. No. If it were moved to before the i18n match for *.xml files it would prevent that code from working since the first match in which the generator is executed is the *only* match that will run. Is there a reason why you want to move it earlier? Ross
Re: [RT] Why using views - in comparison with old fashion skins - usecase i18n.
Thorsten Scherler wrote: On Sun, 2005-06-05 at 14:37 +0100, Ross Gardler wrote: Thorsten Scherler wrote: ... So I was going to ask you to write a simple How-To on creating a new contract, and then embedding it in my own site. Yeah I can understand that. Did you see whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/src/documentation/content/xdocs/index.xml I will extend that with this RT and write a howto. Yeah, I did, but it didn't help much. I'm a bit slow, I need a set of instructions, I found that doc left too many unanswered questions. Of course, I could ask them onlist, and will do so when I have the time to properly discuss and experiment. However, since this RT made me thin ah... I get it I'd hate for it to be lost in the mail archives. I need as well to write some slides for the upcoming workshop about views. How did you do it again within forrest. ;-) Answered in another mail since it is another subject. Ross
Using Forrest for presentations
Thorsten Scherler wrote: I need as well to write some slides for the upcoming workshop about views. How did you do it again within forrest. ;-) You need the s5 plugin http://forrest.apache.org/0.7/docs/plugins/#s5 . This is not available in our SVN because it includes some GPL code. You can create your slides in OpenOffice Impress or you can mark sections as being a slide with @class=slide, or you can even let the plugin guess at what the bullets should be. As with all my plugins there are some demo's in the package. I've used the plugin for a number of presentations, but it is still a 0.1 release, let me know if you find problems. Ross
Re: [Proposal] reply-to: forrest-dev
Thorsten Scherler wrote: Hello devs, I propose to set the reply-to header of this mailing list to forrest-dev by default. How can I do that (as moderator) and should I call a vote before doing it? salu2 ¿?¿?¿?¿?¿ is not the default behaviour? I can see this: Reply-To: dev@forrest.apache.org
Re: Locationmap now works for repositories
On 6/5/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: After reading, studying *.xmap, and re-reading, I think I'm understanding this a bit better. My question is should the locationmap match be moved earlier in the pipeline? I got the behaviour I would have expected by moving it immediately before all of the i18n matches for regular source content. No. If it were moved to before the i18n match for *.xml files it would prevent that code from working since the first match in which the generator is executed is the *only* match that will run. Is there a reason why you want to move it earlier? Because a match in xdocs takes precedence over locationmap right now. I guess it only matters because I was using the samples directory to play around with Slide and I have a samples directory in both Slide and xdocs -- xdocs always wins.I guess I didn't have to worry about the other code running because I'm essentially using the locationmap to point everything in xdocs to Slide right now. Except of course site.xml and tabs.xml which are handled differently than other content in xdocs. Also, are you looking into expanding it for resource (graphics specifically) content too? --tim
Re: pdf-link and txt-link in views
I added the real txt-link into trunk. Thx for the report. Muchas gracias de nada :) Couple of suggestions: o keep the contracts consistent. For instance, the div tag in pdf-link has an id of 'pdf', while the one in txt-link has a _class_ of 'podlink' o since we expect only one pdf-link and txt-link per page, I suggest removing the class attribute from txt-link and simply giving it an id of 'txt-link' (and change id in pdf-link to 'pdf-link') o whats with the class 'dida' in those contracts? :) Great work! -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
Re: pdf-link and txt-link in views
Forgot one more thing: The *-link contracts currently generate a br/ tag after the link. I don't think this is a good idea, since it interferes with the layout. Ideally, we can just leave the div tags and let the skin authors worry about the placement. -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
preview of new skin
Hi everyone, I'm working on a new skin using views/viewHelper. Its nothing fantastic. Just has the following goals: o minimalistic, yet functional view o use as few images as possible (read none, apart from the txt/pdf icons) o render reliably across majority of browsers. You can check it out on my home page: http://resolute.ucsd.edu/diwaker/index.html Its still very much under development and needs a lot of polishing still. So I'll appreciate any comments and feedback :) Diwaker -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
Re: preview of new skin
On Sun, 2005-06-05 at 12:10 -0700, Diwaker Gupta wrote:
Hi everyone,
I'm working on a new skin using views/viewHelper. Its nothing
fantastic. Just has the following goals:
o minimalistic, yet functional view
o use as few images as possible (read none, apart from the txt/pdf icons)
o render reliably across majority of browsers.
I like it. Actually since we dropped the css support on a contract base
we need a default.css for the viewHelper.xhtml. That is the only reason
why I have not deleted the css stuff out of the contracts.
Something with the above mentioned goals would work great for us right
now. The scale-dev is very nice but I do not have the time to keep the
css in sync with the contracts. The goal for a 0.2 version of the plugin
(I hope to release that before ApacheCon) is not a shiny skin but a
practical, meeting the above mentioned goals.
I am +1 to use your skin as dev version for views this will allow to
concentrate on the contracts and not the css.
Can we use yours? Then I do not have to worry anymore about tweaking the
scale-dev and finally got rid of the css-overhead.
For submitting a skin with view/viewHelper you will need to provide the
following resources (* - required):
a)* default.fv
b)* default.css
c) additional-contracts (*.ft)
Actually I am thinking about changing the 'default' naming to
{skin-name}.fv/css in the matching code, that will enable different
skins more easy.
WDYT?
You can check it out on my home page:
http://resolute.ucsd.edu/diwaker/index.html
:( - ;-) you have been faster then me. :)
Now I cannot put on my future homepage first page ever done with
forrest:view because you just put it online.
Just kidding, congratulations and thanks to show the world what views
can do for you. ;-)
Its still very much under development and needs a lot of polishing
still. So I'll appreciate any comments and feedback :)
I want it :). That is what we need as base for the viewHelper.xhmtl.
Please submit a patch. :)
Diwaker
Thanks again
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: [Proposal] reply-to: forrest-dev
On Wed, 2005-06-01 at 11:28 +0200, Juan Jose Pablos wrote: Thorsten Scherler wrote: Hello devs, I propose to set the reply-to header of this mailing list to forrest-dev by default. How can I do that (as moderator) and should I call a vote before doing it? salu2 ¿?¿?¿?¿?¿ is not the default behaviour? I can see this: Reply-To: dev@forrest.apache.org This rule seems only be meet if reply-to header is not set. I am talking about *forcing* reply-to [EMAIL PROTECTED] ;-) salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Locationmap now works for repositories
Tim Williams wrote: On 6/5/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: After reading, studying *.xmap, and re-reading, I think I'm understanding this a bit better. My question is should the locationmap match be moved earlier in the pipeline? I got the behaviour I would have expected by moving it immediately before all of the i18n matches for regular source content. No. If it were moved to before the i18n match for *.xml files it would prevent that code from working since the first match in which the generator is executed is the *only* match that will run. Is there a reason why you want to move it earlier? Because a match in xdocs takes precedence over locationmap right now. Yes, this is by design. The assumption is that it is more efficient to use a local file than a remote one and so the local file takes precedence if it is present. Besides, if we don't give priority to local files it will break backward compatability, which we cannot do. In the final version of the Locationmap system it is likely that *all* files will be served via the locationmap which will have a default of serving from the local filesystem. However, I'm not sure how to do this without breaking the i18N stuff, at least not yet. Note that the locationmap is not actually scheduled until 0.9. It is likely that it will first be added as an alpha feature into 0.8-dev once 0.7 is released. This will have to go to a community vote though. ... of course site.xml and tabs.xml which are handled differently than other content in xdocs. They are, but they need not be. This is something that needs to be addressed. We should be able to get site.xml and tabs.xml from the locationmap source too. Also, are you looking into expanding it for resource (graphics specifically) content too? Yes. My goal is to be able to use the locationmap for everything. However, this is a pretty big job and could introduce many unexpected bugs so would need lots of testing. As you get more comfortable with sitemaps and the like, perhaps you can help (hint resources are handled by the resources.xmap file). Ross
Re: preview of new skin
Thorsten Scherler wrote:
I like it. Actually since we dropped the css support on a contract base
we need a default.css for the viewHelper.xhtml. That is the only reason
why I have not deleted the css stuff out of the contracts.
Something with the above mentioned goals would work great for us right
now. The scale-dev is very nice but I do not have the time to keep the
css in sync with the contracts. The goal for a 0.2 version of the plugin
(I hope to release that before ApacheCon) is not a shiny skin but a
practical, meeting the above mentioned goals.
I am +1 to use your skin as dev version for views this will allow to
concentrate on the contracts and not the css.
Can we use yours? Then I do not have to worry anymore about tweaking the
scale-dev and finally got rid of the css-overhead.
For submitting a skin with view/viewHelper you will need to provide the
following resources (* - required):
a)* default.fv
b)* default.css
c) additional-contracts (*.ft)
Actually I am thinking about changing the 'default' naming to
{skin-name}.fv/css in the matching code, that will enable different
skins more easy.
I like it too, and I'm glad to see that there is some progress that is
visible to end users! I would like to continue to maintain scale-dev but
I have ran into problems with view/viewHelper, namely the lack of a
getting started guide. I'm sure that will be fixed after 0.7 is out
and everyone has more time to work on the next-generation features, as
hopefully somebody will also want to work on documentation. For now, I
would be very grateful if somebody (Thorsten ;-)) could point me in the
right direction for getting views working from the HEAD version.
As for the aesthetics, I think that the skin does a good job where it
is, but I would like to see it have more features before it reaches
the status of default skin, so in other words I would like to make it
more slick. I particularly like the fact that it renders as intended
across browsers, which is not something that I could say about the
original scale-dev!
Thorsten, I would like to continue to work on scale-dev, so if you can
help me to get off the ground with view/viewHelper I would be more than
happy to write a css patch and touch up the front end. However, it's
great to see an alternative view, and it's even better to see it in
production. Good work!
#shaun
Re: preview of new skin
I *really* like it. Especially if it is using views. Fantastic! Thanks :) Some observations: http://resolute.ucsd.edu/diwaker/articles/index.html The first bullet in the lists (not the TOC) have a blank line. http://resolute.ucsd.edu/diwaker/articles/why-forrest.html (and many other pages) there is a change in font towards the end of Take One. I think this is to do with an unclosed anchor in the TOC. I'm not sure I like the visited links font, it seems to get lost alongside the unvisited links. However, I understand why you have done this and I may grow to like it. Perhaps the contrast between visited and unvisited links is just a bit too extreme. Overall a superb skin, and very exciting because it is built with views rather than the old fashioned skinning system. Actually something is terribly wrong with the recent versions of Firefox. They don't render the skin correctly. I have validated the XHTML on validator.w3.org and apart from the namespace issue, the skin validates *perfectly*. Konqueror has no problems rendering it either. Both the issues that you mentioned (the space in the first TOC entry and the change in font) are a result of that. If you look at the DOM tree under Firefox, for some strange reason it is not constructing the DOM tree properly. I'm still trying to figure out the reason. But check out the theme in konqueror and you should see it as I see it here :) The other guiding principle in my theme is to NOT dictate the fonts used. I only specify the generic font family (sans, serif, monospace) if at all, so that the user can use his/her favourite defaults. In the skin, the only difference between visited and unvisited links is the bold font weight. Other than that fonts should not be different. Thanks for the feedback, I'll submit a patch soon :) -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
Re: preview of new skin
I am +1 to use your skin as dev version for views this will allow to
concentrate on the contracts and not the css.
Can we use yours? Then I do not have to worry anymore about tweaking the
scale-dev and finally got rid of the css-overhead.
Sure!
For submitting a skin with view/viewHelper you will need to provide the
following resources (* - required):
a)* default.fv
b)* default.css
c) additional-contracts (*.ft)
Coming up. Should I put them on Jira or just post to the list? I'll go
with JIRA for now.
Actually I am thinking about changing the 'default' naming to
{skin-name}.fv/css in the matching code, that will enable different
skins more easy.
WDYT?
Hmm. Sounds ok, except I haven't got a name for my skin as of now :(
Creative minds please come forth. I'm inclined to call it
minimalistic :D
Diwaker
--
Diwaker Gupta
http://resolute.ucsd.edu/diwaker
using jtidy by default: calling cocoon experts to help!
Hi everyone, I know that Forrest allows using JTidy to clean up raw-HTML pages. I would like to use JTidy by default to clean up the HTML *after the final processing stage*. Right now the HTML that is produced is ok, but a nicely formatted HTML would be nice (and easier to debug!) I not comfortable with Cocoon pipelines, so can any Cocoon expert guide me on this? Thanks, Diwaker -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
Re: preview of new skin
On Sun, 2005-06-05 at 15:10 -0700, Diwaker Gupta wrote:
I am +1 to use your skin as dev version for views this will allow to
concentrate on the contracts and not the css.
Can we use yours? Then I do not have to worry anymore about tweaking the
scale-dev and finally got rid of the css-overhead.
Sure!
:)
For submitting a skin with view/viewHelper you will need to provide the
following resources (* - required):
a)* default.fv
b)* default.css
c) additional-contracts (*.ft)
Coming up. Should I put them on Jira or just post to the list? I'll go
with JIRA for now.
+1 for jira (ever). ;-)
Actually I am thinking about changing the 'default' naming to
{skin-name}.fv/css in the matching code, that will enable different
skins more easy.
WDYT?
Hmm. Sounds ok, except I haven't got a name for my skin as of now :(
Creative minds please come forth. I'm inclined to call it
minimalistic :D
Ok, now I have to think how to in-cooperate this new needs (hope to get
set up Shean quickly and we can directly deliver with two example
skins). ;-)
I reckon a new element in the forrest.properties would be the best. e.g.
view.xhmtl.skin.name=minimalistic
or
view.xhmtl.skin.name=scale
...but if this skins are official part of forrest then I guess they have
to meet:
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/main/webapp/skins/new-skin-names.txt
Diwaker
saludos
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: preview of new skin
Diwaker Gupta wrote: Some observations: http://resolute.ucsd.edu/diwaker/articles/index.html The first bullet in the lists (not the TOC) have a blank line. http://resolute.ucsd.edu/diwaker/articles/why-forrest.html (and many other pages) there is a change in font towards the end of Take One. I think this is to do with an unclosed anchor in the TOC. ... Actually something is terribly wrong with the recent versions of Firefox. They don't render the skin correctly. I have validated the XHTML on validator.w3.org and apart from the namespace issue, the skin validates *perfectly*. Konqueror has no problems rendering it either. Hmmm... this prompted me to look at it in IE, and the problems are worse there. The bullets are completely missing (the text is there, it is only the bullets that are gone), the changing font is still there and the text wraps below the menu nav bar like this: navigation | body text | more boy text - more body text more body text Nevertheless, it is great to see this happening in views. A little work on the CSS and the above problems will be fixed. Ross
Re: preview of new skin
Thorsten Scherler wrote: On Sun, 2005-06-05 at 15:10 -0700, Diwaker Gupta wrote: I reckon a new element in the forrest.properties would be the best. e.g. view.xhmtl.skin.name=minimalistic or view.xhmtl.skin.name=scale As long as it is not added to the default properties, that would serve to confuse users not using the plugin. Ross
Re: does checksums-uri in cli.conf work?
Ross Gardler wrote: Ferdinand Soethe wrote: David Crossley wrote: Cocoon-related questions would get better answers on cocoon-users. Is there an easy way to do this w/o subscribing to their list? My mailbox is already getting a bit crowded :-) You might be able to send email to their list without being subscribed, then follow the replies by browsing their archives on the web. A good place to start would be their archives. There may be some discussion about how to use it and its effects in the user list. There will almost certainly be some discussion about how and why it was implemented in the dev list. Actually all of the initial development was done on their users list. --David See http://cocoon.apache.org/community/mail-archives.html The Cocoon docs are also a good place to look. They are not well organised but they are reasonably complete. Judicious use of the search facility may help (note docs are split between the website and their wiki so two searches will be required). I'll try that and compare the results (Though diff is a Unix-only command, but I know what you mean). I'd recommend installing Cygwin if you are on Windows. You get a much more powerful shell and you can use proper *nix commands as given on the list. See http://www.cygwin.com/ Ross
[jira] Updated: (FOR-520) new skin using views
[ http://issues.apache.org/jira/browse/FOR-520?page=all ] Diwaker Gupta updated FOR-520: -- Attachment: minimalistic.zip Added zip file. Contains default.fv and default.css. No additional contracts required. new skin using views Key: FOR-520 URL: http://issues.apache.org/jira/browse/FOR-520 Project: Forrest Type: Improvement Components: Skins (general issues) Versions: 0.8 Reporter: Diwaker Gupta Priority: Minor Attachments: minimalistic.zip This is a new skin using views that I have been working on. You can see it in action here: http://resolute.ucsd.edu/diwaker I'll be attaching the zip file shortly. -- 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: does checksums-uri in cli.conf work?
Ferdinand Soethe wrote:
Trying to test the checksums-uri in cli.conf, I got really confused
and I'm not sure what is happening. Did I miss something or are there
indeed several nonfunctional settings in cli.conf?
I'd appreciate some comments on this.
As we already said, cocoon-users list.
Some tiny comments below ...
Here is what I did
1. Seeded a new forrest site in mysite
2. Create new dir
3. Copied P:\forrest\main\webapp\WEB-INF\cli.xconf to mysite
4. Added new line
project.configfile=${project.home}/src/documentation/conf/cli.xconf
below
#project.translations-dir=${project.content-dir}/translations
5. Added the setting
checksums-uri../checksums/checksums-uri
below the commented section.
6. Did a 'forrest site'
Now I should have found a new directory build/checksums.
But I did't.
I checked the rest of the forrest tree. No difference.
7. To be sure I created the directory and did a 'forrest site' once
again.
Nothing changed. New dir remained empty.
8. No I changed the setting (to be sure mir cli.xconf was processed)
dest-dir../site/dest-dir
to
dest-dir../sitetest/dest-dir
9. Deleted build and did a 'forrest site'
Output was still written to build/site.
10. Finally I added
exclude pattern=**/*.html/
and found that no more html-page where written to site.
My Conclusion:
I had modified the correct cli.conf.
The exclude pattern is recognized.
The other options are not processed.
Regarding point 8 ...
http://issues.apache.org/jira/browse/FOR-480
Perhaps your point 5 caused it to write to main/site/checksums/
--David
[views] Survival guide and setup
On Sun, 2005-06-05 at 23:01 +0100, Shaun Evans wrote:
I like it too, and I'm glad to see that there is some progress that is
visible to end users! I would like to continue to maintain scale-dev but
I have ran into problems with view/viewHelper, namely the lack of a
getting started guide. I'm sure that will be fixed after 0.7 is out
and everyone has more time to work on the next-generation features, as
hopefully somebody will also want to work on documentation. For now, I
would be very grateful if somebody (Thorsten ;-)) could point me in the
right direction for getting views working from the HEAD version.
I will write a howto on that I promise! For now try the following
survival guide:
*setup*
1) The first step is to build the view and the viewHelper plugins (that
will be easier in the future, we promise)
cd {forrest-trunk}
svn up
cd whiteboard/plugins/org.apache.forrest.plugin.internal.view/
ant local-deploy
cd ../org.apache.forrest.plugin.output.viewHelper.xhtml/
ant local-deploy
2) Then seed an new project:
cd ~/src/newSeed
forrest seed
3) Then add the plugins to the forrest.properties:
project.required.plugins=org.apache.forrest.plugin.output.viewHelper.xhtml,org.apache.forrest.plugin.internal.view
4) Change the project skin to leather-dev (we exchanging only
site2xhtml.xsl of that skin by the plugins and some contracts are based
on e.g. document2html.xsl output of leather-dev)
project.skin=leather-dev
5) prepare default.fv directory (project.conf-dir)
mkdir src/documentation/conf
6) Now you have finished the preparation and the setup to finally try
forrest run
Note: When developing styles with views 'forrest run' is the quickest
way. You will see you do not have to build your project to see the
changes on your pages when working with *.fv.
*changing views* - *.fv
For changing the view of a page, you can start by copying
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/views/default.fv
to e.g. index.fv. This view *has to* be in the same dir as the document
(e.g. index.xml). This is defined in forrest.properties by
#project.xdocs-dir=${project.content-dir}/content/xdocs
To change the default view of your project you have to create a
default.fv (copy above mentioned) in the dir defined in the
forrest.properties by
#project.conf-dir=${project.content-dir}/conf
I now assume you have the following files new added to the seed (if you
did not change any default props):
src/documentation/conf/default.fv
src/documentation/content/xdocs/index.fv
Now the rule for the view matching is
1.) page specific view (e.g. index.fv)
2.) default view (src/documentation/conf/default.fv)
Lets try this rule by changing in index.fv:
!--forrest:contract name=grouplogo/--
save and test:
http://localhost:/index.html
You will find that the grouplogo will not be rendered. Now let test how
the other pages look like:
http://localhost:/samples/sample.html
You see again the grouplogo. To change it in all pages we have to edit
src/documentation/conf/default.fv.
Now all pages do not have the grouplogo. For further information see
e.g. http://marc.theaimsgroup.com/?l=forrest-devm=111800598325769w=2
*CSS support*
Note: Right now we still have the css generation out of contracts but
that will be history as soon we can provide a default.css that is doing
this job. You will find in samples/sample.html (as indicator):
link href=../skin/contracts-samples/sample.css rel=stylesheet
type=text/css /
Now to add your own css to the view:
http://marc.theaimsgroup.com/?t=11136081541r=1w=2n=7
Basically you have to add
forrest:css url=someCss.css/
to the view to add your own css-stylesheet.
This tag has to be direct son from forrest:view!
In the resource.xmap of the plugins we defined a matching rule for
custom css:
map:when test={project:skins-dir}{path}/{name}.css
That means e.g.
forrest:css url=prosimii-screen-alt.css/
would expect (with default values)
src/documentation/skins
|-- css
`-- prosimii-screen-alt.css
For programming contracts see my recent thread and the upcoming how-to
(where you can find a lot of what you just read) ;-).
HTH
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: [Proposal] reply-to: forrest-dev
Thorsten Scherler wrote: Juan Jose Pablos wrote: Thorsten Scherler wrote: Hello devs, I propose to set the reply-to header of this mailing list to forrest-dev by default. How can I do that (as moderator) and should I call a vote before doing it? salu2 ? is not the default behaviour? I can see this: Reply-To: dev@forrest.apache.org This rule seems only be meet if reply-to header is not set. I am talking about *forcing* reply-to [EMAIL PROTECTED] ;-) As cheche has said, the Reply-To header is already set to forrest-dev, so nothing needs to change. Perhaps your mail client is messing up. For me, the replies go to forrest-dev as expected. If that header was not set, then this reply would go directly to you, which it does not. Nothing needs to be changed. --David
Re: preview of new skin
On Sun, 2005-06-05 at 23:01 +0100, Shaun Evans wrote: I like it too, and I'm glad to see that there is some progress that is visible to end users! I would like to continue to maintain scale-dev but I have ran into problems with view/viewHelper, namely the lack of a getting started guide. I'm sure that will be fixed after 0.7 is out and everyone has more time to work on the next-generation features, as hopefully somebody will also want to work on documentation. For now, I would be very grateful if somebody (Thorsten ;-)) could point me in the right direction for getting views working from the HEAD version. As for the aesthetics, I think that the skin does a good job where it is, but I would like to see it have more features before it reaches the status of default skin, so in other words I would like to make it more slick. I particularly like the fact that it renders as intended across browsers, which is not something that I could say about the original scale-dev! Thorsten, I would like to continue to work on scale-dev, so if you can help me to get off the ground with view/viewHelper I would be more than happy to write a css patch and touch up the front end. However, it's great to see an alternative view, and it's even better to see it in production. Good work! See the [views] Survival guide and setup that should bring you up to work. ;-) Yes I really like the scale-dev. If you can come up with patches like http://issues.apache.org/jira/browse/FOR-520 that would be great. #shaun salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: preview of new skin
On Sun, 2005-06-05 at 16:19 -0700, Diwaker Gupta wrote:
Actually something is terribly wrong with the recent versions of
Firefox. They don't render the skin correctly. I have validated the
XHTML on validator.w3.org and apart from the namespace issue, the skin
validates *perfectly*. Konqueror has no problems rendering it either.
Hmmm... this prompted me to look at it in IE, and the problems are worse
there.
I have verified that (in both IE and Firefox) the problems are due to
those vestigial namespace declarations in the html tag and the
feedback tag. Everything works fine otherwise.
I had brought up this issue earlier, but never got around to fixing
it. From that discussion it was apparent that these attributes are
left-overs from the processing pipeline and certainly not required for
the final output. Should I go ahead and look into getting rid of them?
I hope I fixed it in trunk (e.g. txt-link.ft):
Index:
org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/txt-link.ft
===
---
org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/txt-link.ft
(revision 180112)
+++
org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/txt-link.ft
(working copy)
@@ -26,10 +26,8 @@
xsl:stylesheet version=1.1
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template name=txt-link-body
-div class=podlink title=Plain Text Documentation
- a href={$filename-noext}.txt class=dida img
class=skin
-src={$skin-img-dir}/txtdoc.png alt=TXT - icon /br/
TXT/a
-/div
+a href={$filename-noext}.txt class=format img
class=skin
+ src={$skin-img-dir}/txtdoc.png alt=TXT - icon /div
class=captionTXT/div/a
/xsl:template
/xsl:stylesheet
/forrest:template
HTH
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: preview of new skin
On Mon, 2005-06-06 at 00:10 +0100, Ross Gardler wrote: Thorsten Scherler wrote: On Sun, 2005-06-05 at 15:10 -0700, Diwaker Gupta wrote: I reckon a new element in the forrest.properties would be the best. e.g. view.xhmtl.skin.name=minimalistic or view.xhmtl.skin.name=scale As long as it is not added to the default properties, that would serve to confuse users not using the plugin. Yes, I agree. This will be a workaround until views can be used with project.skin and should not go in a fresh seed. Ross salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: preview of new skin
On Mon, 2005-06-06 at 02:40 +0200, Thorsten Scherler wrote: I hope I fixed it in trunk (e.g. txt-link.ft): I just committed. hopes that is better now. ;-) salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[jira] Commented: (FOR-510) Setting Environment Variables Information
[ http://issues.apache.org/jira/browse/FOR-510?page=comments#action_12312705 ] David Crossley commented on FOR-510: No need for special instructions for Mac OS X (== UNIX) unless you are meaning the old Mac OS. Setting Environment Variables Information - Key: FOR-510 URL: http://issues.apache.org/jira/browse/FOR-510 Project: Forrest Type: Improvement Components: Documentation and website Versions: 0.7-dev Reporter: Addison Berry Priority: Minor Since we describe how to set the Forrest env variables in our docs we should make sure we have instructions for varying OS and versions. If you know of an OS that sets variables differently than that listed in our current docs, please add it in the comments. Make sure you state the OS and version as well as the full process to set the Forrest variables. Current instructions (0.7) In Unix/Linux: change directory to the top-level of the forrest distribution and do ~/apache-forrest-0.7$ export FORREST_HOME=`pwd` ~/apache-forrest-0.7$ export PATH=$PATH:$FORREST_HOME/bin In Windows: Go to My Computer, Properties, Advanced, Environment Variables and add: FORREST_HOME as C:\full\path\to\apache-forrest-0.7 PATH as %PATH%;%FORREST_HOME%\bin -- 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: preview of new skin
On Sun, 2005-06-05 at 16:19 -0700, Diwaker Gupta wrote: Actually something is terribly wrong with the recent versions of Firefox. They don't render the skin correctly. I have validated the XHTML on validator.w3.org and apart from the namespace issue, the skin validates *perfectly*. Konqueror has no problems rendering it either. Hmmm... this prompted me to look at it in IE, and the problems are worse there. I have verified that (in both IE and Firefox) the problems are due to those vestigial namespace declarations in the html tag and the feedback tag. Everything works fine otherwise. I had brought up this issue earlier, but never got around to fixing it. From that discussion it was apparent that these attributes are left-overs from the processing pipeline and certainly not required for the final output. Should I go ahead and look into getting rid of them? You mean the namespaces? Like: html xmlns:forrest=http://apache.org/forrest/templates/1.0; xmlns:xi=http://www.w3.org/2001/XInclude; I added a strip_namespaces.xsl to the last output step. That will get rid of *all* namespaces. I do not know whether we have to tweak it to allow some, but that will time tell (or you). ;-) HTH salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[jira] Reopened: (FOR-465) Logging Error: Writing event to closed stream.
[ http://issues.apache.org/jira/browse/FOR-465?page=all ] David Crossley reopened FOR-465: Assign To: (was: David Crossley) You must be confused. This message still exists. Logging Error: Writing event to closed stream. -- Key: FOR-465 URL: http://issues.apache.org/jira/browse/FOR-465 Project: Forrest Type: Bug Components: Launch 'forrest' Versions: 0.7-dev Reporter: David Crossley Priority: Minor Fix For: 0.7-dev After doing 'forrest' there is a strange error message at the end of Cocoon's run: Logging Error: Writing event to closed stream. This happens on every different project that i have tried. -- 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: preview of new skin
On Sun, 2005-06-05 at 21:55 +0100, Ross Gardler wrote: Diwaker Gupta wrote: Hi everyone, I'm working on a new skin using views/viewHelper. Its nothing fantastic. Just has the following goals: o minimalistic, yet functional view o use as few images as possible (read none, apart from the txt/pdf icons) o render reliably across majority of browsers. You can check it out on my home page: http://resolute.ucsd.edu/diwaker/index.html Its still very much under development and needs a lot of polishing still. So I'll appreciate any comments and feedback :) I *really* like it. Especially if it is using views. Fantastic! Some observations: http://resolute.ucsd.edu/diwaker/articles/index.html The first bullet in the lists (not the TOC) have a blank line. http://resolute.ucsd.edu/diwaker/articles/why-forrest.html (and many other pages) there is a change in font towards the end of Take One. I think this is to do with an unclosed anchor in the TOC. I think this is the content-contracts that I am refactoring. I will try a quick fix before sleep. ;-) salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[jira] Assigned: (FOR-520) new skin using views
[ http://issues.apache.org/jira/browse/FOR-520?page=all ] Thorsten Scherler reassigned FOR-520: - Assign To: Thorsten Scherler new skin using views Key: FOR-520 URL: http://issues.apache.org/jira/browse/FOR-520 Project: Forrest Type: Improvement Components: Skins (general issues) Versions: 0.8 Reporter: Diwaker Gupta Assignee: Thorsten Scherler Priority: Minor Attachments: minimalistic.zip This is a new skin using views that I have been working on. You can see it in action here: http://resolute.ucsd.edu/diwaker I'll be attaching the zip file shortly. -- 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] Closed: (FOR-520) new skin using views
[ http://issues.apache.org/jira/browse/FOR-520?page=all ] Thorsten Scherler closed FOR-520: - Resolution: Fixed I appllied the patch to trunk. Thanks. I guess in the beginning we will focus on the bugs of the selected contracts. ;-) Mostly it is the content-contract that causes bugs. new skin using views Key: FOR-520 URL: http://issues.apache.org/jira/browse/FOR-520 Project: Forrest Type: Improvement Components: Skins (general issues) Versions: 0.8 Reporter: Diwaker Gupta Assignee: Thorsten Scherler Priority: Minor Attachments: minimalistic.zip This is a new skin using views that I have been working on. You can see it in action here: http://resolute.ucsd.edu/diwaker I'll be attaching the zip file shortly. -- 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: preview of new skin
On Mon, 2005-06-06 at 03:43 +0200, Thorsten Scherler wrote:
On Sun, 2005-06-05 at 21:55 +0100, Ross Gardler wrote:
Diwaker Gupta wrote:
Hi everyone,
I'm working on a new skin using views/viewHelper. Its nothing
fantastic. Just has the following goals:
o minimalistic, yet functional view
o use as few images as possible (read none, apart from the txt/pdf icons)
o render reliably across majority of browsers.
You can check it out on my home page:
http://resolute.ucsd.edu/diwaker/index.html
Its still very much under development and needs a lot of polishing
still. So I'll appreciate any comments and feedback :)
I *really* like it. Especially if it is using views. Fantastic!
Some observations:
http://resolute.ucsd.edu/diwaker/articles/index.html The first bullet in
the lists (not the TOC) have a blank line.
http://resolute.ucsd.edu/diwaker/articles/why-forrest.html (and many
other pages) there is a change in font towards the end of Take One. I
think this is to do with an unclosed anchor in the TOC.
I think this is the content-contracts that I am refactoring. I will try
a quick fix before sleep. ;-)
:) Now I can go to sleep. ;-)
The bug was/is in common but since it seems not to cause troubles in the
other skins I just fixed it in leather-dev for now.
+ !-- Generate a a name=... tag for an @id --
+ xsl:template match=@id
+xsl:if test=normalize-space(.)!=''
+ a name={.}#160;/a
+/xsl:if
+ /xsl:template
xsl:template match=section
-a name={generate-id()}/
+a name={generate-id()}#160;/a
salu2
I recommend you to make an update of your production site. ;-)
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: Locationmap now works for repositories
On 6/5/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: On 6/5/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: After reading, studying *.xmap, and re-reading, I think I'm understanding this a bit better. My question is should the locationmap match be moved earlier in the pipeline? I got the behaviour I would have expected by moving it immediately before all of the i18n matches for regular source content. No. If it were moved to before the i18n match for *.xml files it would prevent that code from working since the first match in which the generator is executed is the *only* match that will run. Is there a reason why you want to move it earlier? Because a match in xdocs takes precedence over locationmap right now. Yes, this is by design. The assumption is that it is more efficient to use a local file than a remote one and so the local file takes precedence if it is present. Besides, if we don't give priority to local files it will break backward compatability, which we cannot do. Right, sounds good. I guess i jumped the gun a bit in thinking it a bug -- I'd spent a couple hours figuring it out and got overly pleased with myself i guess:( In the final version of the Locationmap system it is likely that *all* files will be served via the locationmap which will have a default of serving from the local filesystem. However, I'm not sure how to do this without breaking the i18N stuff, at least not yet. Note that the locationmap is not actually scheduled until 0.9. It is likely that it will first be added as an alpha feature into 0.8-dev once 0.7 is released. This will have to go to a community vote though. ... of course site.xml and tabs.xml which are handled differently than other content in xdocs. They are, but they need not be. This is something that needs to be addressed. We should be able to get site.xml and tabs.xml from the locationmap source too. I've got both of these working with locationmap now, let me know if that's preferable. This makes me wonder how default locationmaps will be set up. Is there a concept of fallback locationmaps sorta like sitemaps do (e.g., allow project overrides to forrest pre-defined)? I guess the question is: have you a grander design yet for how these things will actually work when it comes to *all* resources? It seems like this idea of overriding the forrest locationmap settings with the project locationmap settings seems necessary? Also, are you looking into expanding it for resource (graphics specifically) content too? Yes. My goal is to be able to use the locationmap for everything. However, this is a pretty big job and could introduce many unexpected bugs so would need lots of testing. As you get more comfortable with sitemaps and the like, perhaps you can help (hint resources are handled by the resources.xmap file). Clearly there's a lot left to learn but I'm no longer as intimidated with the *xmaps -- frightening as it may be, they're actually beginning to make sense now. Having looked at resources.xmap though, I agree, it is going to be a big job. Before looking more at it though, I'd like to get your vision of how it should work. Seems to me there needs to be some sort of forrest:locationmap and project:locationmap concepts in place first? In other words as the locationmap concept is carried over to forrest assets as well as project assets, should each not have a overridable locationmap? --tim
Re: Handling raw HTML
Ross Gardler wrote:
Ross Gardler wrote:
I would like to suggest yet another alternative for 0.7 for the issue of
raw HTML. This would be one in the form of a FAQ, a link to the FAQ from
the upgrade doc and a demo in fresh-site - in other words there is no
complex implementation to hold 0.7 up further.
The FAQ would give the following sitemap match which should be placed in
the project sitemap in order to duplicate the 0.6 behaviour.
map:match pattern=**.html
map:select type=exists
map:when test={project:content}{0}
map:read src={project:content}/{0} mime-type=text/html/
!--
Use this instead if you want JTidy to clean up your HTML
map:generate type=html src={project:content}/{0} /
map:serialize type=html/
--
/map:when
/map:select
/map:match
...
I'm going to implement this unless someone spots a fatal flaw in my plan
(lazy consensus is in operation)
I know I have only let a day go by, but I am truly convinced this is the
best solution for 0.7 so I've gone ahead an implemented it. If anyone
does object or find a problem I will take the responsibility to revert
the changes.
In the meantime I would appreciate it if some could test I have
correctly emulated the 0.6 behaviour and see if the docs in fresh-site
are clear. I still have to do the FAQ and the update document.
It seems to work as described.
However there is a huge problem. The fix should remain as an FAQ only.
Because you have added the match to the default sitemap for a fresh-site,
then everyone who generates a 'forrest seed site' will have this workaround
for 0.6 behaviour, rather than the new 0.7 behaviour. In fact, this has
also broken the demonstrations of the 0.7 behaviour e.g. the Emembedded HTML
sample.
--David
Re: Locationmap now works for repositories
Ross Gardler wrote: I can't remember who wrote the locationmap code it was so long ago. It was Unico Hommes, a Cocoon developer. svn log java/org/apache/forrest/locationmap/lm/LocationMap.java --David
[jira] Commented: (FOR-514) Do not limit status.xml contexts in project info plugin
[
http://issues.apache.org/jira/browse/FOR-514?page=comments#action_12312710 ]
David Crossley commented on FOR-514:
(Bringing over a comment and a patch from Cyriaque Dupoirieux which were added
during the move of our Jira.)
- Udpate of the Status DTD 1.3 in order to be able to add the following
information :
actionContexts
context id=code title=Changes to the Code Base/
context id=docs title=Changes to the Documentation/
!-- ... --
/actionContexts
- Update of changes2document.xsl in order to take into account the context
title or by default the context ID.
- Update of status.xml files (with documentation associated in comments)
Do not limit status.xml contexts in project info plugin
---
Key: FOR-514
URL: http://issues.apache.org/jira/browse/FOR-514
Project: Forrest
Type: Improvement
Components: Plugin: projectInfo
Reporter: Ross Gardler
Priority: Minor
(This comment brought over from FOR-487)
This improvement of changes page is nice.
I have my own version based on xsl:key definition in order to be able to
simply manage as many contexts as you can define (My Dtd is not limited to
build|docs|code|admin|design.
The advantage - on my opinion - is that my own contexts are very various and
not developpement oriented nor language dependant.
here a short example - using releaseNote... :
http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html
The following code replace the 5 blocks xsl:if test=[EMAIL
PROTECTED]'build'] :
titleVersion xsl:value-of select=@version/ (xsl:value-of
select=@date/)/title
+ xsl:for-each
select=action[generate-id()=generate-id(key('contextes',concat(../@version,
'_', @context)))]
+ xsl:sort select=@context/
+ section
+ titlexsl:value-of select=@context//title
+ ul
+ xsl:apply-templates select=key('contextes',concat(../@version, '_',
@context) )
+ xsl:sort select=@type/
+ /xsl:apply-templates
+ /ul
+ /section
+ /xsl:for-each
Hope you'll like the idea...
Regards,
Cyriaque,
--
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-514) Do not limit status.xml contexts in project info plugin
[ http://issues.apache.org/jira/browse/FOR-514?page=all ]
David Crossley updated FOR-514:
---
Attachment: 514-patch.txt
Do not limit status.xml contexts in project info plugin
---
Key: FOR-514
URL: http://issues.apache.org/jira/browse/FOR-514
Project: Forrest
Type: Improvement
Components: Plugin: projectInfo
Reporter: Ross Gardler
Priority: Minor
Attachments: 514-patch.txt
(This comment brought over from FOR-487)
This improvement of changes page is nice.
I have my own version based on xsl:key definition in order to be able to
simply manage as many contexts as you can define (My Dtd is not limited to
build|docs|code|admin|design.
The advantage - on my opinion - is that my own contexts are very various and
not developpement oriented nor language dependant.
here a short example - using releaseNote... :
http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html
The following code replace the 5 blocks xsl:if test=[EMAIL
PROTECTED]'build'] :
titleVersion xsl:value-of select=@version/ (xsl:value-of
select=@date/)/title
+ xsl:for-each
select=action[generate-id()=generate-id(key('contextes',concat(../@version,
'_', @context)))]
+ xsl:sort select=@context/
+ section
+ titlexsl:value-of select=@context//title
+ ul
+ xsl:apply-templates select=key('contextes',concat(../@version, '_',
@context) )
+ xsl:sort select=@type/
+ /xsl:apply-templates
+ /ul
+ /section
+ /xsl:for-each
Hope you'll like the idea...
Regards,
Cyriaque,
--
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
cocoon protocols
I'd like to clarify my understanding of the use of cocoon protocols in forrest. The cocoon documentation says: # context:// - get a resource using the servlet context # cocoon:/ - get a pipeline from the current sitemap # cocoon:// - get a pipeline using the root sitemap # resource:// - get a resource from the context classloader 1) Are cocoon:/ and cocoon:// interchangable within the conceptual sitemap space of forrest (e.g., \main\webapp\*.xmap)? Anecdotally, nothing seems to break when I modify existing ones. 2) The same doesn't appear to hold true of forrest-core.xconf as things do break if the correct one isn't used. Since all of them here are to the root sitemap (e.g., cocoon://) is forrest-core.xconf outside the forrest conceptual sitemap? 3) Are project specific sitemap.xmaps are separate root sitemaps or extensions of the forrest application sitemap? Sorry for the elementary questions... Thanks, --tim
Re: preview of new skin
Wow, too many mails in a flurry! :) I can't reply to all of them, but let me just say 'perfecto! muy bien señor!!' :) This thread has become quite long, I think I'll start a new one for the rest of my mail. I recommend you to make an update of your production site. ;-) Done! -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
