zone for testing 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. Okay, accounts are set up for antonio, rgardler, cheche. When any other committers want one, then ask me. So you need to scp your key to forrest.zones.apache.org Then you can ssh in, change your password, and configure your account. Any difficulties, then ask on our dev list. This page will help: http://www.apache.org/dev/solaris-zones.html I have not created any UNIX groups yet. We are all in the default group other. -0- Now to start a little planning, so that we can get on with testing. I have a forrestbot (just the cron side of it, not the user interface) running in my home directory to help the Cocoon people with the generation of their development documentation for their trunk. Later that will probably move to the shared zone being proposed on the site-dev mail list as we don't want to be providing ad-hoc infrastructure services for other projects (unless it is planned to be so). So what services do we want to establish? We would need either Tomcat or Jira so that we can test our webapp in a servlet container. We also would run the forrestbot webapp interface there, probably building the seed site and maybe our trunk website. We already have an Apache HTTP Server 2.0 on port 80. I suppose that we would use ProxyPass etc. to hide the servlet container. How do we make people aware that this is not our production website? I have already added a robots.txt to keep the honourable ones out. --David
Re: zone for testing forrest
On Vie, 27 de Mayo de 2005, 1:03, David Crossley dijo: 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. Okay, accounts are set up for antonio, rgardler, cheche. Thanks. So you need to scp your key to forrest.zones.apache.org Then you can ssh in, change your password, and configure your account. Any difficulties, then ask on our dev list. This page will help: http://www.apache.org/dev/solaris-zones.html I saw the link, perhaps we can setup the default profile for all the users as stated in the link: PATH=/usr/bin:/usr/sfw/bin:/usr/sfw/sbin:/opt/sfw/bin: \ /opt/sfw/sbin:/opt/SUNWspro/bin:/usr/X/bin:/usr/ucb: \ /usr/sbin:/usr/ccs/bin:/opt/subversion-1.1.4/bin Also, will be fine to set bash as the default shell for all the users too. People using linux will love that. ;-) snip/ So what services do we want to establish? Perhaps a distribution of plugins? Is posible to distribute there some skins? I still remember our idea that was reject by sourceforge. Also, I noted we are running in the zone java 1.5_01, perhaps we should move to 1.5_03? ;-) We would need either Tomcat or Jira so that we can test our webapp in a servlet container. We also would run the forrestbot webapp interface there, probably building the seed site and maybe our trunk website. We already have an Apache HTTP Server 2.0 on port 80. I suppose that we would use ProxyPass etc. to hide the servlet container. How do we make people aware that this is not our production website? I have already added a robots.txt to keep the honourable ones out. Perhaps as brutus does. A home page stating: Beaware: This is only a demo site. Or something like that. Best Regards, Antonio Gallardo.
Re: zone for testing forrest
Antonio Gallardo wrote: David Crossley dijo: David Crossley wrote: David Crossley wrote: I saw the link, perhaps we can setup the default profile for all the users as stated in the link: PATH=/usr/bin:/usr/sfw/bin:/usr/sfw/sbin:/opt/sfw/bin: \ /opt/sfw/sbin:/opt/SUNWspro/bin:/usr/X/bin:/usr/ucb: \ /usr/sbin:/usr/ccs/bin:/opt/subversion-1.1.4/bin Yes that would be good. For the moment i have just added it to my own ~/.bash_profile Also, will be fine to set bash as the default shell for all the users too. People using linux will love that. ;-) Not just Linux people. I would be prefer bash. I have just configured it as my own default. snip/ So what services do we want to establish? Perhaps a distribution of plugins? Is posible to distribute there some skins? I still remember our idea that was reject by sourceforge. This is ASF equipment, so rules about licensing are still the same. My question was rather about whether to use Tomcat or Jira, etc. See below. Also, I noted we are running in the zone java 1.5_01, perhaps we should move to 1.5_03? ;-) That is a global zone thing. If you want Java updated then need to ask at infrastructure@ list. It will apply to all zones. We would need either Tomcat or Jira so that we can test our webapp in a servlet container. We also would run the forrestbot webapp interface there, probably building the seed site and maybe our trunk website. We already have an Apache HTTP Server 2.0 on port 80. I suppose that we would use ProxyPass etc. to hide the servlet container. How do we make people aware that this is not our production website? I have already added a robots.txt to keep the honourable ones out. Perhaps as brutus does. A home page stating: Beaware: This is only a demo site. Or something like that. That is easy for the front page, but each page of content is more difficult. For the moment stopping Google from indexing is a good start. --David
Re: zone for testing forrest
David Crossley wrote: Antonio Gallardo wrote: David Crossley dijo: David Crossley wrote: David Crossley wrote: ... We would need either Tomcat or Jira so that we can test our webapp in a servlet container. We also would run the forrestbot webapp interface there, probably building the seed site and maybe our trunk website. I would propose Tomcat for the simple reason that it will force us to test another aspect of Forrest, i.e. the generation of the WAR and hosting on a different servlet container. We already have an Apache HTTP Server 2.0 on port 80. I suppose that we would use ProxyPass etc. to hide the servlet container. How do we make people aware that this is not our production website? I have already added a robots.txt to keep the honourable ones out. Perhaps as brutus does. A home page stating: Beaware: This is only a demo site. Or something like that. That is easy for the front page, but each page of content is more difficult. For the moment stopping Google from indexing is a good start. Use a different site/project logo? Add it to the MOTD? Ross
Re: Locationmaps and Lenya integration
On Thu, 2005-05-26 at 18:20 -0400, Gregor J. Rothfuss wrote: 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. I agree. 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. I never said that this DSL will do anything other then configuring. Java is for devs and not users, but user can use a simple configuration language to configure the java classes. That is a simple interface for SOC. *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. :) To do so you need a common interface for components (or tools) to plugin into the framework. This is best expressed in a DSL because you can capsule the parameter passed to the tools/components. [OT] Create new publication - that should work IMO like forrest seed. Anywhere on your hd executable and not limited to be within lenya site structure. If we can provide this we as well would be copyless like forrest which is one of the biggest advantage of forrest over lenya for developing webappz. 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. Agree. 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? Because you can not do everything with css. The css only can be applied to certain xhtml-skeletons. The designer wants to have control over the produced skeleton with the views we will give him this possibility. Then he really can use the css he wants the way he want it. 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? That user that do not have to learn java to extend and use lenya/forrest. They want to configure and not program. ...and you are right it is a layer of indirection but I do not see anything bad on that. ...and I *really truly* believe it is easier to use and learn a DSL that contains right now 4 different tags and configure your classes with that. The benefit is that other components can use the same DSL to be configured. That will make component development much easier because you have a clear DSL for configuration. In short views are the missing link between user and devs. I started the work on it because I saw that our forrest skins are sharing *a lot* of common components but as soon as we change some components than I have to apply the changes in all skins. By capsuling this components into contracts the maintainment and use of this components is much easier. 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) :) LOL Yeah you are right. Search the ml for view;view helper;leather;... cool, will do. some links http://marc.theaimsgroup.com/?l=forrest-devm=110107619329543w=2 mailings href=http://marc.theaimsgroup.com/?; dev href=l=forrest-devamp; pInfra href=m=110019697426791amp;w=2/ ftLeather
[JIRA] Created: (FOR-508) available-skins command returns incorrect information
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-508 Here is an overview of the issue: - Key: FOR-508 Summary: available-skins command returns incorrect information Type: Task Status: Unassigned Priority: Minor Project: Forrest Versions: 0.6 Assignee: Reporter: Maurice Lanselle Created: Fri, 27 May 2005 5:27 AM Updated: Fri, 27 May 2005 5:27 AM Environment: Win XP (but I don't think that matters in this case). Description: Forrest available-skins command returns incorrect information, including a skin (crust) which no longer exists, and omitting some (plain-dev, leather-dev) which are available (but not fully supported). - 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-509) Deprecated skin designated to replace non-existant skin
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-509 Here is an overview of the issue: - Key: FOR-509 Summary: Deprecated skin designated to replace non-existant skin Type: Task Status: Unassigned Priority: Minor Project: Forrest Assignee: Reporter: Maurice Lanselle Created: Fri, 27 May 2005 5:51 AM Updated: Fri, 27 May 2005 5:51 AM Description: In forrest.build.xml, a skin-aliasing occurs to replace skins which no longer exist by an alternative, and a warning is issued. Similarly, a warning is issued when a deprecated skin is chosen. It can happen that a deprecated skin is designated to replace a no-longer-existing skin: this should be avoided to prevent confusion. Maintenance should ensure that only non-deprecated (i.e. supported) skins are designated replacements each time the build file is updated or skins are deprecated. - 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: How to Try Currently Useable Skins?
[This discussion has migrated to dev issues, I've cc'd the dev list and
subsequent replies will go there, if you want to follow along you need
to join the dev list]
Maurice Lanselle wrote:
Ross Gardler said the following on 26/05/2005 22:07:
Thank you for taking the time to address my questions, I'm sure you have
plenty else to do.
Yes, this is true, we welcome patches for improvements once you
understand things. Right now I'll try and help you get through the
inadequate docs.
I will gladly contribute to the documentation once I understand things.
And so our time is well spent :-)
2) Customize the colors of the chosen skin.
This is not as simple or successful as I expected. There seems to be
inconsistent information on what skins are currently useable, and
also the inclusion of their color tags in skinconf.xml.
a) The available-skins command gives out-of-date information :
crust, pelt, tigris
We only actively support pelt. All other skins are either in
development or deprecated, although some are still usable (you can
find out what they are by looking in the skins directory of the
distribution).
Checking my Forrest.home, I see my /context/skins/ has common,
krysalis-site, forrest-site, leather-dev as well as pelt,
plain-dev, and tigris; it is forrest.build which prevents access to
them. Why not just remove them from the distribution?
This is a good question, if it is not possible to use them why are they
present. I will bring this up on the dev list.
Note that common is used by other skins and provides common behaviour
between them.
Pelt is clean and effective, I just wonder how different a Forrest site
can look-and-feel. As I've done with my (local) wiki and blog and, to a
lesser extent, with spip. I'm a bit disoriented with Forrest because I
don't understand the code (more comfortable with php), but that will pass.
Q. How different can it look?
A. Totally different, there are no limitations
Skins are a collection of XSL stylesheets that take the internal formats
and arrange the content within a plain XHTML file. Since everything is
controlled by XSL the way this XHTML file is organised is *completely*
under the control of the skin.
The XHTML produced by the XSL's is then styled using the CSS.
In otherwords layout is controlled by XSL, style by CSS.
Of course, you can do the layout in CSS as well if you so desire.
There are, theoretically, no limitations in the skinning process. In
fact, you need not produce HTML. For example, the FO stylesheets produce
Formatting Objects (from which we create PDF). If you use the Text
plugin you get plain text output. If you use the POD plugin you get
Plain Old Documentation format.
You comment above indicates that the list provided by availabl-skins
is out of date, please raise an issue for us so we can remember to fix
it for the upcoming 0.7 release.
Okay, I'll add the issue. I guess I expected the command to scan the
souce of skins (much as forrest.build.xml can do using property
name=forrest.skins-dir location=${forrest.home}/context/skins/ )
to see what is available (the approach many apps use for cataloguing
available plug-ins) rather than consult a stored list which requires
maintenance.
The reason for the list is that there is a skin package system that
allows third parties to provide skins that are not a part of the Forrest
distribution. Forrest therefore cannot scan a directory to find the
skins since some of them can be hosted elsewhere.
Ideally, each skin would have a file (rdf ?) in the spirit
of .htaccess or .cvsignore which would enable forrest to know the status
and facilitate the aliasing that is currently handled in
forrest.build.xml.
Yes, I agree. In fact the meta-data idea is something I have been
considering for the plugins framework.
I believe that skins should, like plugins, be
expected to conform to certain standards, but need not be developed by
the Forrest project; to manage them by name in forrest.build.xml seems
to me to add an unnecessary centralisation of skin administration by
making it the build file maintainer's job rather than the skin
maintainer's. But I certainly don't claim that there are not good
reasons for it being the way it is.
It *should* work the way you describe, like plugins. In fact when I
built the plugins infrastructure I copied the download and install
mechanism from the skins packaging mechanism.
If this has subsequently been broken then it needs to be fixed. Please
make this not in your issue (copy this discussion since you highlight
some key points). Unfortunately, the skin packaging system has not
really been used, therefore it doesn't get tested. I would like to see
it being utilised in the same way that plugins are, as you describe.
I think Tim Williams's annotation for skinconf would have helped me, and
it is a welcome addition.
Indeed it is a welcome addition, that is now in SVN thanks Tim (and
[JIRA] Updated: (FOR-509) Deprecated skin designated to replace non-existant skin
The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Fri, 27 May 2005 6:28 AM Comment: Scheduled for 0.7 release Changes: type changed from Task to Improvement Version changed to 0.6 Component changed to Skins (general issues) Fix Version changed to 0.7-dev - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-509?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-509 Here is an overview of the issue: - Key: FOR-509 Summary: Deprecated skin designated to replace non-existant skin Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Fix Fors: 0.7-dev Versions: 0.6 Assignee: Reporter: Maurice Lanselle Created: Fri, 27 May 2005 5:51 AM Updated: Fri, 27 May 2005 6:28 AM Description: In forrest.build.xml, a skin-aliasing occurs to replace skins which no longer exist by an alternative, and a warning is issued. Similarly, a warning is issued when a deprecated skin is chosen. It can happen that a deprecated skin is designated to replace a no-longer-existing skin: this should be avoided to prevent confusion. Maintenance should ensure that only non-deprecated (i.e. supported) skins are designated replacements each time the build file is updated or skins are deprecated. - 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-508) available-skins command returns incorrect information
The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Fri, 27 May 2005 6:25 AM Comment: Reclassified to be fixed in the 0.7 release Changes: type changed from Task to Bug priority changed from Minor to Major Component changed to Skins (general issues) Fix Version changed to 0.7-dev - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-508?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-508 Here is an overview of the issue: - Key: FOR-508 Summary: available-skins command returns incorrect information Type: Bug Status: Unassigned Priority: Major Project: Forrest Components: Skins (general issues) Fix Fors: 0.7-dev Versions: 0.6 Assignee: Reporter: Maurice Lanselle Created: Fri, 27 May 2005 5:27 AM Updated: Fri, 27 May 2005 6:25 AM Environment: Win XP (but I don't think that matters in this case). Description: Forrest available-skins command returns incorrect information, including a skin (crust) which no longer exists, and omitting some (plain-dev, leather-dev) which are available (but not fully supported). - 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
Skins
Are pelt, tigris, and common the only current skins? The rest (corium, forrest-site, krysalis-site, leather-dev, plain-dev) appear to be either under development or deprecated. Also, is there a clear way to determine which skins are deprecated? I'd like to take on FOR-508 and FOR-509 as they appear trivial enough for me to grasp. Thanks, --tim
Re: Skins
Tim Williams wrote: Are pelt, tigris, and common the only current skins? The rest (corium, forrest-site, krysalis-site, leather-dev, plain-dev) appear to be either under development or deprecated. Also, is there a clear way to determine which skins are deprecated? The only officially supported skin is pelt. I'm not exactly sure of the status of tigris, someone else will clarify I hope. plain-dev is still in development, however, I actually use it as part of Burrokeet so I would be +1 for it being officially supported. Others are as you say. I'd like to take on FOR-508 and FOR-509 as they appear trivial enough for me to grasp. Excellent :-)) If you need any help just ask. We'll point in the right direction. Ross
Re: [JIRA] Updated: (FOR-509) Deprecated skin designated to replace non-existant skin
Unless I've oversimplified this, here's the change for this. crust now goes to pelt. Skin aliasing for backwards compatability 0.5 = 0.6 krysalis-site = ... warn about future removal forrest-site = ... warn about future removal crust = pelt forrest-css = pelt avalon-tigris = tigris tigris-style = tigris I wasn't sure whether that version info should change or not? --tim On 5/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Fri, 27 May 2005 6:28 AM Comment: Scheduled for 0.7 release Changes: type changed from Task to Improvement Version changed to 0.6 Component changed to Skins (general issues) Fix Version changed to 0.7-dev - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-509?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-509 Here is an overview of the issue: - Key: FOR-509 Summary: Deprecated skin designated to replace non-existant skin Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Fix Fors: 0.7-dev Versions: 0.6 Assignee: Reporter: Maurice Lanselle Created: Fri, 27 May 2005 5:51 AM Updated: Fri, 27 May 2005 6:28 AM Description: In forrest.build.xml, a skin-aliasing occurs to replace skins which no longer exist by an alternative, and a warning is issued. Similarly, a warning is issued when a deprecated skin is chosen. It can happen that a deprecated skin is designated to replace a no-longer-existing skin: this should be avoided to prevent confusion. Maintenance should ensure that only non-deprecated (i.e. supported) skins are designated replacements each time the build file is updated or skins are deprecated. - 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 for-509.patch Description: Binary data
Re: [JIRA] Updated: (FOR-509) Deprecated skin designated to replace non-existant skin
Tim Williams wrote: Unless I've oversimplified this, here's the change for this. crust now goes to pelt. Excellent, thanks for your contribution. Please attach to the issue, it may get lost in the mail lists as I don;t have time to apply it right now. Ross
Re: Skins
Tim Williams wrote: Is plain-dev really included by default? Yes plain-dev - success, but no resources found, images, script etc. and they don't exist in the skins folder either. Well it is in development :-)) Ross
[JIRA] Updated: (FOR-509) Deprecated skin designated to replace non-existant skin
The following issue has been updated: Updater: Tim Williams (mailto:[EMAIL PROTECTED]) Date: Fri, 27 May 2005 9:13 AM Comment: Unless I've oversimplified this, here's the change for this. crust now goes to pelt. Skin aliasing for backwards compatability 0.5 = 0.6 krysalis-site = ... warn about future removal forrest-site = ... warn about future removal crust = pelt forrest-css = pelt avalon-tigris = tigris tigris-style = tigris I wasn't sure whether that version info should change or not? --tim Changes: Attachment changed to for-509.patch - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-509?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-509 Here is an overview of the issue: - Key: FOR-509 Summary: Deprecated skin designated to replace non-existant skin Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Fix Fors: 0.7-dev Versions: 0.6 Assignee: Reporter: Maurice Lanselle Created: Fri, 27 May 2005 5:51 AM Updated: Fri, 27 May 2005 9:13 AM Description: In forrest.build.xml, a skin-aliasing occurs to replace skins which no longer exist by an alternative, and a warning is issued. Similarly, a warning is issued when a deprecated skin is chosen. It can happen that a deprecated skin is designated to replace a no-longer-existing skin: this should be avoided to prevent confusion. Maintenance should ensure that only non-deprecated (i.e. supported) skins are designated replacements each time the build file is updated or skins are deprecated. - 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] Closed: (FOR-507) xml-fop *.xmap files
Message: The following issue has been closed. Resolver: David Crossley Date: Fri, 27 May 2005 8:12 PM Closing, because this was not the problem. - 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: Closed Priority: Minor Resolution: WON'T FIX Project: Forrest Components: Other Versions: 0.6 Assignee: Reporter: Clay Leeds Created: Thu, 26 May 2005 11:51 AM Updated: Fri, 27 May 2005 8:12 PM 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: Skins
Ross Gardler wrote: Tim Williams wrote: Are pelt, tigris, and common the only current skins? The rest (corium, forrest-site, krysalis-site, leather-dev, plain-dev) appear to be either under development or deprecated. Also, is there a clear way to determine which skins are deprecated? The only officially supported skin is pelt. I'm not exactly sure of the status of tigris, someone else will clarify I hope. It is a copy of the skin from style.tigris.org as mentioned at http://forrest.apache.org/0.7/docs/skins.html#tigris See also the notes in forrest/main/webapp/skins/tigris/README.txt We can accept patches for the Forrest components of the skin. The trouble is that the community is not providing many contributions. Look at 'svn log' for the various files, there have been occasional changes. I personally don't use it and would rather use pelt for now, and later the viewHelper stuff, so i have no itch to enhance it. However that does not prevent the community from enhancing it. One thing to bear in mind is that the css files are not ours, they are a copy from tigris.org site. If ever we update the tigris copy then we need to be sure that we do not clobber our changes. See the notes in 'svn log' and the README.txt --David
