incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [www] html instead of markdown (mdtext)?
Date Thu, 11 Aug 2011 22:14:52 GMT
Hi Kay,

On Aug 11, 2011, at 2:38 PM, Kay Schenk wrote:

> On Thu, Aug 11, 2011 at 12:44 PM, Rob Weir <apache@robweir.com> wrote:
> 
>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
>>> I am proposing that we adopt plain HTML for the OOo website instead of
>> the
>>> current markdown (mdtext) implementation.
>>> 
>>> I hesitate to make this recommendation given ALL the time and research
>> Dave
>>> and others have already spent on the current incubator website, but, I
>> feel,
>>> given that we will be migrating a rather large existing site, it makes
>>> sense.
>>> 
>> 
>> Where can I find the sources for the current website?  Not the wiki
>> stuff, but the parts that you think would be difficult to migrate?
>> 
> 
> Oh boy...all over the place! Each OO.o project has its own svn repository
> with this stuff!
> What I was trying to say, given my paltry knowledge, was that it would be
> impossible to convert the whole OO.o site to markdown. This was my point.

That is now quite clear. I definitely want to preserve the html although it will be transformed.

> 
> However, I am now reading about the Apache CMS more carefully, and see
> this...
> 
> "The build system relies on lib/path.pm to provide a specially formatted
> @patterns array to give the build system hints on which *view* to run for a
> given source file. The patterns are checked in order, and if none of the
> patterns match, the source file will simply be copied over to the build
> tree."

The key part. The template subroutine is picked here.

> 
> This tells me if we did not specify ANY patterns, that everything would be
> copied to the *actual* Apache web site as is, which would be fine! However,
> we do need template processing.

Exactly ...

> 
> 
>>> I also realize that doing this will "break" the ability to use the webgui
>>> editing capability of the Apache CMS, forcing everyone to use svn for
>> page
>>> updates. However, I don't have a good feel right now for the ultimate
>> impact
>>> of that -- e.g. what do we expect in terms of web site editors.
>>> 
>>> This would allow us to continue to use the default template system
>>> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
>>> text with normal HTML. HTML files shouldn't require any "wrapping"
>> functions
>>> at all I think, since this is the indigenous format for web servers. We
>>> would have to bypass header, footer and navigation items for anything
>> that
>>> *isn't* html, like js, css files.
>>> 
>> 
>> We should also consider that the best approach might be to not do
>> mdtext and not do Dotiac::DTL, but to adopt a newer framework.
>> 
> 
> heh...yeah, I thought of that, but since any new "framework", i.e. template
> system, must work with perl this would necessitate a module install by the
> Apache infra folks. Really, I am trying to suggest the "path of least
> resistance". We can work with the default framework for now as long as we
> don't get too crazy.

If you want to look at what is possible then use the bookmarklet to look into www.apache.org.
This page is published hourly and the top three projects are shuffled while twitter and jira
and other feeds are picked off. WIthout a huge amount of work we could do something similar
for openoffice.org.


>>> Unfortunately, I've had a very difficult time this week trying to find
>> any
>>> information on the setup details of Dotiac::DTL (documentation not
>>> available) -- the relationship of the two .pm files to the template
>> areas,
>>> etc.
>>> 
>>> I took at look around at many the Apache web areas (svn) at:
>>> 
>>> http://svn.apache.org/repos/asf/
>>> 
>>> You will see, as I did, that the vast majority are not using markdown,
>> and
>>> this is NOT a requirement.
>>> 
>>> Anyway, thoughts/comments on this proposal?
>> 
>> HTML is not a panacea, of course.  It is very easy to design pages
>> that look bad, are broken from portability,  internationalization and
>> accessibility standpoint, introduce security issues, etc.  So having a
>> constrained markup can be a good thing for a web site that you expect
>> many people of various skill levels to edit.
>> 
> 
> OK, I know this but I also know anyone who does ANY web development deals
> with an IDE that at its heart deals with HTML. And, really I don't envision
> everyone even wanting to edit the web site ever! The good thing is 1) we can
> always setup test areas, and 2) we have a versioning system! In my 10 yrs of
> dealing with the current OO.o site, I know of no circumstance in which we've
> had an unrecoverable meltdown.
> 
> However, because of what you've told me about Apache and committer's rights
> to projects, things WILL BE different here. Folks will not be quarantined to
> various areas.  I don't know how much of a concern/factor that is to anyone.

Subscribe to ooo-commits@i.a.o and say something if you see a bad commit.

> 
> 
>> Just a thought:  Could you do the entire website in MediaWiki, with
>> only exception cases (download page, etc.) done in HTML?
>> 
> 
> Yes, you could but again...there's the (maybe) conversion problem...HTML ->
> mediawiki.
> 
> Let me do this. I'll try to get a realistic idea over the next few days of
> what I'll call "critical pages" -- those that should really *be* HTML,  and
> we'll see what we've got, and what's left.

This would be good. I'll be investigating the generic transformation for the html.

> 
> A final note that Dave brought up about kenai  *.html and the *.vm files.
> 
> I'm pretty sure the *.vm files were the old Collabnet architecture stuff,
> and can be ignored. Kenai html I haven't a clue about. I suspect they
> control headers, footers and other aspects, like user logins, individual
> project templates which we wouldn't be concerning ourselves with right now
> -- or shouldn't anyway.

Good then we'll check them in to preserve them and then remove them when convenient.

> 
> We need to establish a reasonable goal for our end users. Give them
> something that looks familiar without a lot of the bells and whistles that
> no longer pertain.

+1.

Regards,
Dave

> 
> 
> 
>>> --
>>> ------------------------------------------------------------------------
>>> MzK
>>> 
>>> "Those who love deeply never grow old;
>>> they may die of old age, but they die young."
>>>                       -- Sir Arthur Pinero
>>> 
>> 
> 
> 
> 
> -- 
> ---------------------------------------------------------------------------------------
> MzK
> 
> "Those who love deeply never grow old;
> they may die of old age, but they die young."
>                                -- Sir Arthur Pinero


Mime
View raw message