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]
