Web Stats in Jetty
Is there any web software that can parse Jetty's visitor statistics (Requests, AvePageViewTime,...) to present in a similar way to regular web visit programs (e.g. awstats)? I've looked around but I can't find anything. Jay __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [RT] Serving Apache Forrest site from live Forrest
On Jue, 26 de Mayo de 2005, 5:49, David Crossley dijo: David Crossley wrote: We have now been allocated a zone on the new server. So we need to define our goals and then start setting up some demo servers. We should get out of this RT thread and start planning. But lets concentrate on the 0.7 release first. What do people think about setting up our zone now? It would actually be a good way to test our upcoming release. I can create an account for any forrest committers. +1 ;-) Best Regards, Antonio Gallardo
Re: svn commit: r178548 - /forrest/trunk/site-author/forrest.properties
David Crossley wrote: Ross Gardler wrote: [EMAIL PROTECTED] wrote: Author: crossley Date: Wed May 25 16:33:28 2005 New Revision: 178548 URL: http://svn.apache.org/viewcvs?rev=178548view=rev Log: Restore the required plugin output.POD which was removed in the previous revision. Sorry, I meant to check that before commiting. Why is it required? There is a POD example in the main docs. Here is one place: http://forrest.apache.org/0.7/docs/document-v20.html We had preciously agreed that the main docs don't have samples so that people do not need to download the plugins to build the docs. If we provide samples for everything then everyone has to download all the plugins. Demonstrations of the plugins should be via their documentation on the website, or locally if the plugin has been downloaded. Shall I remove these POD examples and put them in the plugin itself? Ross
Re: [RT] Serving Apache Forrest site from live Forrest
David Crossley wrote: David Crossley wrote: We have now been allocated a zone on the new server. So we need to define our goals and then start setting up some demo servers. We should get out of this RT thread and start planning. But lets concentrate on the 0.7 release first. What do people think about setting up our zone now? It would actually be a good way to test our upcoming release. I can create an account for any forrest committers. +1, I'll help where I can. Ross
Re: [ProjectInfo] where is releaseNotes2document.xsl ?
Cyriaque Dupoirieux wrote: Hi, The stylesheet releaseNotes2document.xsl is in the ProjectInfo.zip but not in the directory of the sources of the plug in. I delete it by making a local-deploy... I don't declare a bug because I think it can be corrected quickly. You're right, it seems I forgot to add it when I did the SVN commit. It's there now, do an svn up Ross
[JIRA] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
The following comment has been added to this issue: Author: Cyriaque Dupoirieux Created: Thu, 26 May 2005 11:12 AM Body: Excellent, but I don't think it's a minor problem. My own skin - originally based on pelt - is now far from the original one generally for translation reason. The ProjectInfo plugin has now the same limits and I also have my own copy of it... The configuration management begins to be complex for me when a file changes... - View this comment: http://issues.cocoondev.org//browse/FOR-506?page=comments#action_12430 - View the issue: http://issues.cocoondev.org//browse/FOR-506 Here is an overview of the issue: - Key: FOR-506 Summary: Do not hard-code site-visible message strings in skin files Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Versions: 0.7-dev Assignee: Reporter: Pedro I. Sanchez Created: Thu, 26 May 2005 10:49 AM Updated: Thu, 26 May 2005 11:12 AM Environment: N/A Description: Text strings like Copyright, Published, and Search are hardcoded into skin files like site2xhtml.xsl. When creating web sites in languages other than English the web developer is forced to create local versions of these skin files with the appropriated translations. Instead, the DTD for the skinconf.xml should be improved to allow these translations to be specified in this file. This would make Forrest much easier to use. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
The following comment has been added to this issue: Author: Ross Gardler Created: Thu, 26 May 2005 11:50 AM Body: Can you describe what you think the problem would be with this propsed solution of extending skinconf.xml? For example: i18n lang=en token name=lastPublished value=Last Published/ token name=copyright value=Copyright/ /i18n i18n lang=?? token name=lastPublished value=???/ token name=copyright value=???/ /i18n This schema allows any token to be added, so customisation of skins would not be a problem. - View this comment: http://issues.cocoondev.org//browse/FOR-506?page=comments#action_12431 - View the issue: http://issues.cocoondev.org//browse/FOR-506 Here is an overview of the issue: - Key: FOR-506 Summary: Do not hard-code site-visible message strings in skin files Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Versions: 0.7-dev Assignee: Reporter: Pedro I. Sanchez Created: Thu, 26 May 2005 10:49 AM Updated: Thu, 26 May 2005 11:50 AM Environment: N/A Description: Text strings like Copyright, Published, and Search are hardcoded into skin files like site2xhtml.xsl. When creating web sites in languages other than English the web developer is forced to create local versions of these skin files with the appropriated translations. Instead, the DTD for the skinconf.xml should be improved to allow these translations to be specified in this file. This would make Forrest much easier to use. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Created: (FOR-507) xml-fop *.xmap files
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-507 Here is an overview of the issue: - Key: FOR-507 Summary: xml-fop *.xmap files Type: Task Status: Unassigned Priority: Minor Project: Forrest Components: Other Versions: 0.6 Assignee: Reporter: Clay Leeds Created: Thu, 26 May 2005 11:51 AM Updated: Thu, 26 May 2005 11:51 AM Environment: Mac OS X Description: xml-fop *.xmap files from $FORREST_HOME/context/*.xmap - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Updated: (FOR-507) xml-fop *.xmap files
The following issue has been updated: Updater: Clay Leeds (mailto:[EMAIL PROTECTED]) Date: Thu, 26 May 2005 11:52 AM Comment: *.xmap files from $FORREST_HOME/context/*.xmap to resolve problem of TOC generation for xml-fop FAQ. Changes: Attachment changed to xml-fop-forrest.zip - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-507?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-507 Here is an overview of the issue: - Key: FOR-507 Summary: xml-fop *.xmap files Type: Task Status: Unassigned Priority: Minor Project: Forrest Components: Other Versions: 0.6 Assignee: Reporter: Clay Leeds Created: Thu, 26 May 2005 11:51 AM Updated: Thu, 26 May 2005 11:52 AM Environment: Mac OS X Description: xml-fop *.xmap files from $FORREST_HOME/context/*.xmap - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: svn commit: r178620 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/saxpath.license.txt /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar.license.txt
[EMAIL PROTECTED] wrote: Log: Add missing license. Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/saxpath.license.txt (with props) forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar.license.txt - copied unchanged from r178612, forrest/trunk/tools/jetty/servlet-2_3.jar.license.txt uppps... I forgot to email about the servlet library. Do we need the servlet.jar file 3 times on our svn? ./lib/core/servlet-2_3.jar ./whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar ./tools/jetty/servlet-2.3.jar I am sure that the core one can be removed. But what about the Chart plugin? Cheers, Cheche
Re: Release notes generation
Ross Gardler wrote: I just committed changes to the projectinfo plugin that will generate release notes for a particular version of forrest from status.xml. If you request http://localhost:/releaseNotes_0.7-dev.html you will Let me know if you can see any improvements to be made. Do we need to keep old copies on our svn? why do we need 10 RELEASE-NOTES-0.* files? Cheers, cheche
[JIRA] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
The following comment has been added to this issue: Author: Pedro I. Sanchez Created: Thu, 26 May 2005 2:26 PM Body: Couple of comments: 1. It could work, but for me to test it I would like to get clarification on two things: a) How do you enable the i18n .. /i18n thing to work? I just put your code in my web site and Forrest complains with skinconf.xml:369:9: Element type i18n must be declared. skinconf.xml:370:50: Element type token must be declared. b) lang=en, what does it mean? If en refers to the system language in the host where the web developer is working (the locale setting) then this doesn't work. I am developing an all-Spanish web site while working in an all english host environment. 2. What about the non-tokenized strings like Search? - View this comment: http://issues.cocoondev.org//browse/FOR-506?page=comments#action_12433 - View the issue: http://issues.cocoondev.org//browse/FOR-506 Here is an overview of the issue: - Key: FOR-506 Summary: Do not hard-code site-visible message strings in skin files Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Versions: 0.7-dev Assignee: Reporter: Pedro I. Sanchez Created: Thu, 26 May 2005 10:49 AM Updated: Thu, 26 May 2005 2:26 PM Environment: N/A Description: Text strings like Copyright, Published, and Search are hardcoded into skin files like site2xhtml.xsl. When creating web sites in languages other than English the web developer is forced to create local versions of these skin files with the appropriated translations. Instead, the DTD for the skinconf.xml should be improved to allow these translations to be specified in this file. This would make Forrest much easier to use. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: svn commit: r178620 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/saxpath.license.txt /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar.license.txt
Juan Jose Pablos wrote: [EMAIL PROTECTED] wrote: Log: Add missing license. Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/saxpath.license.txt (with props) forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar.license.txt - copied unchanged from r178612, forrest/trunk/tools/jetty/servlet-2_3.jar.license.txt uppps... I forgot to email about the servlet library. Do we need the servlet.jar file 3 times on our svn? ./lib/core/servlet-2_3.jar Not sure, see Jetty below ./whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar No - can be removed as long as it is available somewhere in the classpath. ./tools/jetty/servlet-2.3.jar I think this would be the one to keep, but it would need testing. Ross
Re: Release notes generation
Juan Jose Pablos wrote: Ross Gardler wrote: I just committed changes to the projectinfo plugin that will generate release notes for a particular version of forrest from status.xml. If you request http://localhost:/releaseNotes_0.7-dev.html you will Let me know if you can see any improvements to be made. Do we need to keep old copies on our svn? why do we need 10 RELEASE-NOTES-0.* files? They are not in SVN, they are dynamically generated from status.xml when a request of the above format is recieved. Currently there is no link to any release notes within site. One should be added of course, but there is nothing to say that we have to keep it there in a subsequent release. There is duplication in the notes section. I was thinking about moving out some parts into a different file, but that is for another day (or someone else) Ross
[JIRA] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
The following comment has been added to this issue: Author: Ross Gardler Created: Thu, 26 May 2005 2:48 PM Body: My question was to it was to Cyriaque who said your proposal was not sufficient. I was asking why and adding details to the proposal. But since you ask for more info here we go (if this becomes a desgn discussion we should move it to the dev list and then place a summary here). a) How do you enable the i18n .. /i18n thing to work? I just put your code in my web site and Forrest complains with... My example is intended to be a suggestion for how the DTD could be extended to support what you are requesting. It doesn't exist yet. b) lang=en, what does it mean? Forrest has some in development i18n features, this would be one of them. I'm not sure exactly how it works, but somehow Forrest must be told which language to server. This value would be used in the skinning process in order to select the correct language tokens. 2. What about the non-tokenized strings like Search? Currently none of the strings are tokenised. If we adopt this solution then we will need to tokenise them all. This is open source - can you help us since this is your itch? If you want to tackle this discuss it with us on the dev list, we can help by pointing you in the right direction. Otherwise you'll have to wait until a dev finds the time and inclination to implement this, or another solution. - View this comment: http://issues.cocoondev.org//browse/FOR-506?page=comments#action_12434 - View the issue: http://issues.cocoondev.org//browse/FOR-506 Here is an overview of the issue: - Key: FOR-506 Summary: Do not hard-code site-visible message strings in skin files Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Versions: 0.7-dev Assignee: Reporter: Pedro I. Sanchez Created: Thu, 26 May 2005 10:49 AM Updated: Thu, 26 May 2005 2:48 PM Environment: N/A Description: Text strings like Copyright, Published, and Search are hardcoded into skin files like site2xhtml.xsl. When creating web sites in languages other than English the web developer is forced to create local versions of these skin files with the appropriated translations. Instead, the DTD for the skinconf.xml should be improved to allow these translations to be specified in this file. This would make Forrest much easier to use. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Locationmaps and Lenya integration
Thorsten Scherler wrote:
I do not like this expression 'programming in xml' it is more (like I
stated in other threads) 'configuring components with xml'.
the crucial question will be where to draw the boundaries.
This code should help *user* easily change the output of forrest. In the
end this code should be produced by tools.
...and btw I would like to see such clear intuitive configuration and
separation in lenya and not a parameter overkilled framework that allows
user to extend the framework if they *exactly* follow the *not easy* to
understand boundaries and rules of the framework where you can do
everything you want as long it is the lenya way.
what you are proposing as an alternative is a domain-specific language
(DSL). i don't think that is any easier than java, especially
considering that you lose all the nice autocomplete, javadocs,
refactoring, testing etc features that have sprung up around java. it's
not the fault of the language if you use vi to write java when there are
better alternatives available.
*User* want to have a configuration file (or better (in the future) a
tool where they can create such a file) to alter the behavior of their
application. They do not want to learn cocoon/java to alter the default
behavior. You have worked on PostNuke, you should know that for
yourself, as a user you do not want to learn php. ;-)
if you have a tool, you don't need a DSL :) the effort spent on coming
up with a DSL could alternatively be spent on creating wizards for
common functionality, like 'create new publication' in the lenya case.
speaking of postnuke, that was a total disaster, totally unmaintainable
code. take a look at xaraya (and it's history), it's a rewrite that
avoids the problems postnuke has.
The goal is that a normal user do not have to understand much of
programming (nor cocoon or java) but rather can configure forrest in an
easy intuitive way to customize it the way they want. The view e.g.
should be created by a webdesigner that have *no* knowledge of
programming at all.
why not use CSS?
Devs on the other hand want an easy to understand and clear defined
interface where they can plugin new components.
are you suggesting that it is easier to learn and use a DSL than to use
java? i don't buy that, sorry. the DSL is just a layer of indirection,
the real implementation (at least in lenya, dunno about forrest) will be
java classes anyway, so why not try to have a sensible API rather than
hide it behind a bunch of xml?
i like xml as much as anyone, but there are limits (see below for a case
where the limit has been violated in a drastic way)
Search the ml for view;view helper;leather;...
cool, will do.
...or do you *really* consider
logic:filter value=dirCut parameter=p
forrest:view format=inx /
/logic:filter
logic:filter value=actorCut parameter=p
forrest:view format=inx /
/logic:filter
as programming???
if the expressive power of that XML is not severely restricted, then yes.
see http://ant.apache.org/ant2/features.html, heading Simple
Flow-Control for a similar argument.
cocoon moved away from having logic in the sitemap, and lenya 1.4 has
removed all the logic in XSP and other XML places, because XSP turned
out to be brittle: you don't get compile errors if a XSP has calls to an
API that has been removed.
i just refactored a cocoon app that has a 4000 line sitemap. below is a
sample of how things looked before the refactoring. this experience is
the reason why i am asking these questions.
i will try to find your RT to better understand what you have in mind.
best,
-gregor
map:resource name=submitApproved
map:select type=parameter
map:parameter name=parameter-selector-test
value={cct-package:/deliveryMethod}/
map:when test=email
map:act type=resource-load
src=cocoon:/letter.submission
map:parameter name=write-to
value=session/
map:parameter name=attribute-name
value=packageQueue.package/
map:select type=parameter
map:parameter name=parameter-selector-test
value={cct-package:/lsttestmode}/
map:when test=
map:act
type=jmsSender
map:parameter
name=packageID value={cct-package:/id}/
map:parameter name=srcPattern
value=cocoon:/letter.*.*.archive/
map:parameter name=appendSrcPattern
value=cocoon:/letter.*.*.email/
map:parameter name=ccRecipients
value={cct-package:count(/recipient/advisor)}/
map:parameter name=requiredRecipients
Re: Release notes generation
Ross Gardler wrote: Juan Jose Pablos wrote: Ross Gardler wrote: I just committed changes to the projectinfo plugin that will generate release notes for a particular version of forrest from status.xml. If you request http://localhost:/releaseNotes_0.7-dev.html you will Let me know if you can see any improvements to be made. Do we need to keep old copies on our svn? why do we need 10 RELEASE-NOTES-0.* files? They are not in SVN, they are dynamically generated from status.xml when a request of the above format is recieved. Currently there is no link to any release notes within site. One should be added of course, but there is nothing to say that we have to keep it there in a subsequent release. There is duplication in the notes section. I was thinking about moving out some parts into a different file, but that is for another day (or someone else) There are crossed wires here. Cheche was talking about the files in SVN:forrest/etc/RELEASE-NOTES-0.*.txt The relevant file gets added to the release distribution by the Ant build system. You are right Cheche, we do not need to keep release notes for old versions. Just nobody ever tidied up this area. --David
