On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:

What about anything with a .vm extension?

download.apt.vm gets processed as vm first, then apt. We can do that in Doxia with zero-configuration.

I really don't want it on by default, because it'll break existing documents

It won't break any existing documents. If it doesn't parse it just goes back to processing the raw document.

, and I can see situations where we might want to facilitate different processors.

Sure, I'll ponder this a bit more. I don't want it to cause any problems, but zero configuration. What kind of other processors are you thinking about?

Maybe we could make a configuration and allow the options to be configured from the site.xml.

Jason.


- Brett

On 18/03/2007, at 3:35 AM, Jason van Zyl wrote:


On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:

Could this velocity pre-processor just be a plugin that gets run in the
pre-site phase - unrelated to doxia?


It could and that's what the velocity people seem to be doing on their site, but I would really like to not have to configure anything.

I would like it to be useful generally, but if people object to it being on by default (but for static site generation who cares), then maybe a directory structure that gets processed by velocity. But then you end up with a bunch of different directories. What I did was process it with Velocity and if that attempt fails with a parsing error just fall back to processing the raw document.

I want zero configuration, and it just work. I'll do any grunt work to make that possible.

Jason.

Eric

On 3/17/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:

> You've lost me, sorry. What type of page are you trying to create?
>

Any page, Velocity will be used to render any of the pages. It would
just work anywhere in the site.

> I can see how this makes it possible to make lightweight reports. I > don't see how it's useful in most documentation. I would think the
> former would naturally be in a separate section somewhere, as
> opposed to having to specify pages.
>
> I think what Emmanuel was saying was that making everything
> velocity would mean stuff that had things that looked like
> expressions now would end up different (you are trying to explain $
> {project.build.directory} instead of substitute it).

That's really easy to escape, and we can tell people it's a Velocity document and it's well documented. I think that would be easier then juggling pages around to be rendered as it will be the case where you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.

Jason.

>
> - Brett
>
> On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
>
>>
>> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
>>
>>> I think I'd like the option to, but not every time. Maybe it
>>> belongs closer to the reporting infrastructure (the download
>>> pages are more like the SCM/mail list types of pages).
>>>
>>> Maybe that's the real future of those types of pages - the
>>> ability to write simple velocity pages that get processed to spit
>>> out apt that gets added to the list of docs to generate. Rather
>>> than affecting the APT itself, it is a step before
>>>
>>> WDYT?
>>>
>>
>> I'm not sure what you mean, not everytime. I think if you turn it >> on you wouldn't want to have to specify what pages you want to be
>> interpolated. I think that would be inconvenient. And though it
>> doesn't fully stream now it will so it will actually be faster
>> then the current site plugin. So the performance will be higher
>> once it streams instead of collecting the page content in memory
>> to process it. So speed is not going to be an issue and it's not
>> really noticeable right now.
>>
>> This is only for sites and would be very handy. For example would
>> then be able to make new types of reports and share them. They
>> just pop them into their site structure (and move toward being
>> packaged up as reports) and they will render with their project
>> information.
>>
>> I'm leaning toward being on by default and letting people fully
>> utilize Velocity anywhere they like.
>>
>> Jason.
>>
>>> - Brett
>>>
>>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>>>
>>>>
>>>>
>>>> Jason van Zyl a écrit :
>>>>> Hi,
>>>>> Do you think people would like to use Velocity for the pages of >>>>> documentation regardless of format. I've hooked it in to try it
>>>>> but there are a couple options.
>>>>> 1) Use Velocity to process the pages before going to the
>>>>> respective doxia parser
>>>>> 2) Make 1) optional
>>>>> 3) Just interpolate the documents like we do the XML forms of
>>>>> model
>>>>
>>>> We can't interpolate every time. Sometimes, we need to
>>>> interpolate ${project.*} and sometimes not in dox
>>>>
>>>> Emmanuel
>>>>
>>>>> I like the Velocity option, not sure if being on by default or
>>>>> not is good. When there is a parse error I'm currently just
>>>>> rendering the original document as is where you can see a
>>>>> warning and the full error in debug mode. This is for 2.0 so it
>>>>> is a new feature but would allow some cool stuff with.
>>>>> Jason.
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>> ------------------------------------------------------------------- -
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>> ------------------------------------------------------------------- --
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ------------------------------------------------------------------- --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


------------------------------------------------------------------- --
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Eric Redmond
http://codehaus.org/~eredmond


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to