hmm. i'm a bit skeptical of whether all the generic Exception catches
can be removed, but i'm pretty sure i'd be supportive of passing all
(or at least most) RuntimeExceptions through. i personally haven't
hit any problems with the current pattern, but i'm sure things could
be improved. +0.5
Author: wglass
Date: Tue Jan 3 08:23:55 2006
New Revision: 365675
URL: http://svn.apache.org/viewcvs?rev=365675view=rev
Log:
Fixed typo for property directive.parse.max.depth. Thanks to Oliver Kohll for
the catch.
Modified:
jakarta/velocity/core/trunk/xdocs/docs/developer-guide.xml
Disclaimer: This stuff is pushing the edges of my understanding of
Velocity internals; i know how velocimacros behave far better than i
know how they are implemented internally. So, i'm not sure how
competently i can comment here. Nonetheless, here are some
thoughts...
I've long thought
+1
I especially agree with the removal of any exception handling where the
handling is to log the error. as my log files are not read nearly often
enough for this to work.
I wanted to talk a bit about the Uberspect the Testable Uberspect.
I think it is a very good thing to develop
Llewellyn,
Thanks for the idea. I'm not sure changing the behavior from development to
production is a good idea for everyone. It's confusing. Also, the
distinction is not always so clear. In my app the production server
includes pages that are frequently changed by the user (e.g. those
Thanks for the comments on RuntimeExceptions. I'll go ahead and apply this
to the source code.
I think it will simplify life for developers, in particular those writing
plugsins.
And as previously suggested in an earlier thread, for Velocity 2.0 I
definitely want to move to unchecked
Thanks, Nathan...
Appreciate the feedback - I was indeed looking for these types of general
comments rather then specific technical points. Also, I wanted to point out
to the community that we've had repeated bug reports on this item and it's
a feature not a bug, i.e. it's an issue with the
sounds good. and i agree it would be nice to be able to #parse a
macro file and have them work in the parent template.
another thing that might be good to keep in mind for 1.6/2.0 when we
address some of these macro design issues is the possibility of
supporting macros with bodies. i know
Can you give an example of what you mean (macros with bodies)?
Best,
WILL
- Original Message -
From: Nathan Bubna [EMAIL PROTECTED]
To: Velocity Developers List velocity-dev@jakarta.apache.org
Sent: Tuesday, January 03, 2006 11:34 AM
Subject: Re: request for comments on Macro issues
#macro( minilayout $style )
a bunch of stuff...
div style=$style
${BODY}
/div
a bit more stuff...
#end
#minilayout( color: red; )
This stuff should be rendered and then inserted where the BODY
reference is in the macro definition.
#end
at least, that's a rough idea. the body insertion part
Great to hear.
regards Malcolm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1 on the 1.5 macro release approach.
I would also love to see the macro with nested content (I think we are
talking about the same thing) brought in into a Velocity 1.6 release.
In FM they are referred to as the nested directive
Author: wglass
Date: Tue Jan 3 21:30:46 2006
New Revision: 365829
URL: http://svn.apache.org/viewcvs?rev=365829view=rev
Log:
Correct fix to VELOCITY-98. If page writer alternates #parse and #include for
the same file, the file needs to be reloaded (can't reuse the cache).
Modified:
Author: wglass
Date: Tue Jan 3 21:40:24 2006
New Revision: 365831
URL: http://svn.apache.org/viewcvs?rev=365831view=rev
Log:
Here's a better fix to Velocity-98 which caches #include static
text separately from templates. Patch as suggested by
original contributor Michal Chmielewski. Thanks!
[
http://issues.apache.org/jira/browse/VELOCITY-98?page=comments#action_12361710
]
Will Glass-Husain commented on VELOCITY-98:
---
The problem reappeared once we changed the Exception handling code to pass
through RuntimeExceptions. (hooray for
Author: wglass
Date: Tue Jan 3 21:45:40 2006
New Revision: 365832
URL: http://svn.apache.org/viewcvs?rev=365832view=rev
Log:
Pass through RuntimeExceptions from plugins and event handlers.
(except for MethodExceptionEventHandler). VELOCITY-429.
Added:
[ http://issues.apache.org/jira/browse/VELOCITY-429?page=all ]
Will Glass-Husain resolved VELOCITY-429:
Resolution: Fixed
Update applied.
Pass through runtime exceptions
---
Key: VELOCITY-429
[ http://issues.apache.org/jira/browse/VELOCITY-362?page=all ]
Will Glass-Husain updated VELOCITY-362:
---
Bugzilla Id: (was: 33750)
Fix Version: 1.6
(was: 1.5)
This is trickier than it seems. See my thoughts at
[ http://issues.apache.org/jira/browse/VELOCITY-146?page=all ]
Will Glass-Husain updated VELOCITY-146:
---
Bugzilla Id: (was: 17669)
Component: Source
(was: Build)
Fix Version: 1.6
(was: 1.5)
Upon
[
http://issues.apache.org/jira/browse/VELOCITY-414?page=comments#action_12361714
]
Will Glass-Husain commented on VELOCITY-414:
Thanks for contributing. We've been working on improving exception handling
and error reporting. Any chance you
[ http://issues.apache.org/jira/browse/VELOCITY-414?page=all ]
Will Glass-Husain updated VELOCITY-414:
---
Fix Version: 1.5
Extend the MethodInvocation exception to be able to give the velocity macro
writer a usefull error page
[ http://issues.apache.org/jira/browse/VELOCITY-277?page=all ]
Will Glass-Husain updated VELOCITY-277:
---
Bugzilla Id: (was: 29959)
type: Improvement (was: Bug)
Fix Version: 1.6
(was: 1.5)
Upon reflection, this
Author: wglass
Date: Tue Jan 3 22:14:17 2006
New Revision: 365836
URL: http://svn.apache.org/viewcvs?rev=365836view=rev
Log:
Added Implementation-Vendor-Id as recommended in
http://java.sun.com/j2se/1.5.0/docs/guide/extensions/versioning.html
Modified:
[ http://issues.apache.org/jira/browse/VELOCITY-390?page=all ]
Will Glass-Husain resolved VELOCITY-390:
Resolution: Fixed
Added org.apache as Implementation-Vendor-Id.
add MANIFEST.MF to build
Key:
Author: wglass
Date: Tue Jan 3 22:26:13 2006
New Revision: 365843
URL: http://svn.apache.org/viewcvs?rev=365843view=rev
Log:
fixed link to svn repository
Modified:
jakarta/velocity/core/trunk/xdocs/index.xml
Modified: jakarta/velocity/core/trunk/xdocs/index.xml
URL:
[ http://issues.apache.org/jira/browse/VELOCITY-415?page=all ]
Will Glass-Husain resolved VELOCITY-415:
Resolution: Fixed
Updated in source control and on web site (in a couple hours when the mirror is
synchronized, anyway).
Wrong link
26 matches
Mail list logo
