Kay,

Surely this is looking at the issue the wrong way around. HTML is a lower lever of abstraction. Yes, this suggestion makes life easier for the maintainer but at the expense of extra complexity/difficulty for the contributor -- especially as the average contributor isn't at ease working in HTML, so will tend to use some form of WYSIWYG editor. Hence different editors can end up laying out the HTML completely differently if they use different tools to do this, so an svn differencing of two successive versions with minor content changes could end up looking entirely different.

If we are going to HTML then perhaps it might be appropriate on this project to mandate the use of the OOo web editor for editing all such content. Just a thought.

Regards Terry

On 11/08/11 19:55, Kay Schenk wrote:
On Thu, Aug 11, 2011 at 10:13 AM, Dave Fisher<[email protected]>  wrote:

On Aug 11, 2011, at 9:12 AM, Kay Schenk wrote:

I am proposing that we adopt plain HTML for the OOo website instead of
the current markdown (mdtext) implementation.

We can mix and match.

yes, but... mdtext is converted to html anyway. I just think the overhead --
i.e. maintenance by existing and "new" folks -- will be unweildy.


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.

Don't worry about me. What I've learned is useful to me even if we decide
to take another approach.

How do you propose handling all of the Kenai wrapping?

uh...I'll be honest...I am not familiar with the " Kenai wrapping". And I
dare say, probably few are. My *guess* is this in invovled in
headers,footers, and ????

We might be able to ignore whatever this is and just get on with something
WAY simpler for the time being.

The new site won't be registering users and probably doesn't need a lot of
the current *.vm and *.html.html files.

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.

You really CAN edit HTML using the Apache CMS Web-Gui. It is just that I
currently like unwrapped body html.

Oh--OK -- I hadn't tried this and this isn't what the web page about the CMS
indicates.
So, even better.



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.

In the back of my head this week I've been thinking about a way to use
properly formed html and then "rewrap" to apply consistent headers and
footers is forming. The idea is to use an xslt filter to extract html from
the<head>  and<body>.

Well this may be super but unfortunately I am not knowledgable enough to
really know what you're saying here. But isn't this the purpose of the
template system -- to just patch on the headers, footers, anythng else?
Again, I am thinking "project long-term". I think it's vital to put
something in place that the regular web-jockey is familiar with.


For the head - grab various elements including scripts and style. For the
body grab it all. There are at least two advantages:

(1) Each html page can be separated and tested outside of site framework.
(2) Every html page published on the site automatically has the proper
framework.

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.

It took me sometime to understand how it works. If you follow the
instructions on running locally - website-local.mdtext - it ought to work.

OK--I still have NOT done that.  The thing is the instructions still do NOT
give details on the setup of Dotiac::DTL. If I installed that locally, maybe
some documentation would emerge. And I will do that. There's LOADS of info
on django -- but not this perl wrapper.


Perhaps we should IRC tomorrow and we can identify the disconnect in this
documentation.

uh--sorry, I'm unavailable tomorrow. I think YOUR documentation is fine
really for what you're trying to get people to do -- with dealing with
mdtext. But, this is kind of my point.

*IF* we went straight html, and *IF* the templates were setup and fixed in
place -- yes, we'd need a perl/django wonk for this aspect (along with some
MUCH better documentation on this aspect) --  folks wouldn't have to do a
local setup at all. They'd simply edit HTML and commit the way we've always
done in the past. Much simpler in my mind.


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.

It is not a requirement, it was a recommendation. (POI uses a very old
version of Forrest and no one has wanted to change...)

Anyway, thoughts/comments on this proposal?
Let's see if others have something to say. (I've got some Fortran and SQL
to do today.)

yes, good idea...have fun with your project


Regards,
Dave

--
------------------------------------------------------------------------
MzK

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



Reply via email to