Ok, in the end this means we cannot go with this - I am for using
templates in the API and base-classes for everything else.
regards,
Martin
On Feb 7, 2008 6:47 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
This mail is about the wiki http://wiki.apache.org/myfaces/Code_Generation:
An the
Hi
This mail is about the wiki http://wiki.apache.org/myfaces/Code_Generation:
An the topic on this wiki page
Generating base classes instead of templatesFinally I have found the reasons
about my previous suggestions, so I will proceed with the proper update of
the wiki. These are the changes:
Hi
I have checked this topic of the wiki
http://wiki.apache.org/myfaces/Code_Generation:
Generating base classes instead of templatesAnd based on some work with
tomahawk I have some observations to do:
*...Note that (in a feature that may surprise some Java developers) it
appears quite valid
I look at the vast list of bugs raised against tomahawk 1.1.6, and look
at the scary output of the maven reports (findbugs, pmd, etc) and think
that there are higher priorities than reinventing the build process
right now, when the current approach works. Yes it is ugly, but 1.1.7 is
mostly a
Hi Simon,
And this approach is not possible for uicomponent classes defined in the
standard as these have defined hierarchies that cannot be modified.
does this stem from actually trying it out? I tried it in the project
I am currently working on, and it worked. I need to admit I did not
check
Martin Marinschek [EMAIL PROTECTED] schrieb:
Hi Simon,
And this approach is not possible for uicomponent classes defined in the
standard as these have defined hierarchies that cannot be modified.
does this stem from actually trying it out? I tried it in the project
I am currently
Hi Simon, Zdenek,
There is still the question of whether the TCK would pass if classes in
javax.faces had package-scoped parents that are not defined in the spec. Is
there someone here that can check that? If that is allowable, then this
base-class approach becomes much more interesting...
Hi Zdenek,
A question was raised about why state isn't retrieved from the
attributes map - this cannot be used, however, cause it would use
reflection internally and call the getter of the method, if a value is
not directly stored in the attributes map. As soon as the getter is
called, after
Hi all,
some clarifications from my side:
Quote 1:
One of the last developers to work on the old code-generation framework
commented that it was very painful. Not sure whether this comment was
about the basic concept of this approach, or just the implementation.
It was about changes made
Hi,
Simon Kitching napsal(a):
Martin Marinschek [EMAIL PROTECTED] schrieb:
Hi Simon,
And this approach is not possible for uicomponent classes defined in the
standard as these have defined hierarchies that cannot be modified.
does this stem from actually trying it out? I
Hi,
Martin Marinschek napsal(a):
Hi Zdenek,
A question was raised about why state isn't retrieved from the
attributes map - this cannot be used, however, cause it would use
reflection internally and call the getter of the method, if a value is
not directly stored in the attributes map. As
Hi Zdenek,
writing:
- check if special setter - use it AND
- store in map
this won't work, of course - we are in a setter already, so we cannot
use the attribute-map - thanks for setting me straight again. What you
are suggesting would effectively change the API of every single
JSF-component
On Thu, 2008-01-31 at 21:40 +, Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by SimonKitching:
http://wiki.apache.org/myfaces/Code_Generation
Ok, as promised here
Hi Simon,
Ok, as promised here is the wiki page summarising the recent email
thread. I hope I've got everybody's opinions fairly represented, but of
course if corrections need to be made - hack away!
I've added and clarified where I thought it was appropriate.
Personally I'm keen to try to
Okay, feel free to flame.
Possibility of merging annotations w/ code generation:
@Component(
type = ...,
family = ...,
rendererType = ...,
tagClass = ...,
events = {
@ComponentEvent(
type = ...,
phases = { ..., ... }),
...
)
public abstract class MyComponent
@Component(
type = ...,
family = ...,
rendererType = ...,
tagClass = ...,
events = {
@ComponentEvent(
type = ...,
phases = { ..., ... }),
...
)
public abstract class MyComponent extends UIXComponent
{
@ComponentProperty(
description = or is this
http://wiki.apache.org/myfaces/Code_Generation
2) Generating base classes instead of templates from xml-config-files
For what it's worth, what you're describing here is the Generation Gap
pattern. I've got a lot of experience using it with Cayenne over the
years (and WebObjects years before
On Thu, 2008-01-31 at 23:59 +0100, Martin Marinschek wrote:
Personally I'm keen to try to build something along the lines
I was
proposing - but first need to help get a new Orchestra release
out.
If you can solve the problem with restore-state and
18 matches
Mail list logo
