Hi Stefano, First of all thanks for the input. See my comments inside.
2012/5/10 Stefano Bagnara <[email protected]>: > 2012/5/8 Ioan Eugen Stan <[email protected]>: >> The design is not done and there is much to be done but I wanted to >> get some impressions before I continue. Some things that come to my >> mind: >> - integrate with Google search and analytics > > Yes, this is important. Expecially the Analytics part, as we want to > be able to measure things to understand if what we do works or not. > >> - finish integration with twitter >> - design some aggregation pages similar to [2], [3] > > IMO it has a much higher priority to let the CMS skin and the maven > skin to match their look. Once the pages can be mixed together we can > go live, and after this we can start adding new docs/aggregation > pages. > Remember we have maven-generated docs that will probably have to be > interlinked with CMS pages. This page, for example, is automatically > generated by Maven using javadocs and source code, so I don't expect > to be able to move that to CMS: > http://james.apache.org/mailet/standard/mailet-report.html If one tool can do that, means another one will be able to do so, but I'm looking for ways to avoid it. Thanks for mentioning the page is generated. > I prefer our current skin to the new one (as it is right now) because > it is much more readable: > http://james.apache.org/server/3/config-users.html > http://james.staging.apache.org/server/config-users.html > I don't see paragraph titles in the new pages. You are right. Readability will be excellent, I probably should have made it more clear that I concentrated on "general shape" / CSS and not content looks. Most pages are auto-converted from xdoc to mdtext, but not a very good conversion. Now I'm looking into xdoc -> html conversion directly. The idea is to keep our current pages in xdoc, use svn:externals to bring them into site-cms/content space and apply XSLT transformations (in the perl scripts) to build html out of them on the CMS side. This way we will have no conversion errors and keep the docs with the code. Any help with this step is welcomed. I've put some examples from openejb. Did you took a look at them? We can make our pages look like that too, and it's not hard as you can see from the mdtext sources. You can read them as text with ease. Moving to Apache CMS means a consistent view across all components of the project and across all website. It's very easy to do actually, but requires some familiarity with the technology. The steps are: - build a template in templates/ - write a transformation in lib/view.pm that will transform a path according to the template - make a regexp in lib/path.pm that matches paths you wish to apply a given template, and call the view function The only downside is that all this is done in perl, which I have a very hard time reading. We should have a set of templates that we are going to use across all project. I imagine we won't be needing more than 5-7. Templates can use inheritance so it should be even more easy. > I'm not against moving to a new skin/layout, but we should keep > consistency and readability. > Also, make sure urls do not change, so in this case it is missing a > "/3/" in the path. I was (am) trying out some radical new face-lift. Aside for the bad formatting what do you think about the new look and feel? We can bring the existing docs with svn:externals so the urls will remain untouched. Old docs will still be available, but with the old view. In time, we can move them to the new look or phase them out and replace them with a link to the full archive. Cheers, > The idea is that you should just replace "james.apache.org" with > "james.staging.apache.org" to see any page that we're going to move > from maven to CMS. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Ioan Eugen Stan http://ieugen.blogspot.com/ *** http://bucharest-jug.github.com/ *** --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
