Howard Lewis Ship <hlship <at> gmail.com> writes:
> CompoundalidatorGenerator should be named CompoundValidatorGenerator.
Right!
> FormPersistWorker: the BodyBuilder utility is useful for assembling
> Javassist code piecewise.
Thanks for the tip!
> Also, Javassist must have gotten more
> liberal about what it accepts as a "body", it used to be that you had
> to enclose multiple statements inside braces. Maybe extendMethod() is
> different from creating a new method.
The collectFormPersistPropNames() method needs to call
super.collectFormPersistPropNames(). Therefore, I am using extendMethod().
However, it does seem that addMethod() is a safer choice.
> InternalClassTransformationImpl: findFieldsWithAnnotation() has been
> uselessly overriden (the alternate version, with the searchAncestors
> parameter) is not actually used and does not doing anything with that
> parameter.
Right. I forgot to remove it after failed attempt.
> So ... is parameter binding just for informal parameters now?
Yes.
> So ... you have to be explicit about using an Any component?
Yes. It needs a bit more typing (and editing the Java file), but
it enforces a better separation between HTML code and Java code
and makes the configuration code (binding) subject to compile-
time checking, auto-completion and refactoring.
> There's no longer any check for unbound parameters. I guess that too
> is up to individual components to check, probably inside <at> SetupRender.
Yes.
> 5.0.2-SNAPSHOT includes additional annotations for hooking into page
> lifecycle, so <at> PageLoaded would also be good, I guess. I'm finding the
> relationship between parameters and lifecycle a bit fuzzy.
The configure_xxx() method is called just before SetupRender. This allows
the component to render multiple times in a loop. Therefore, I think
PageLoaded is not a suitable moment for configuration.
> So ... for parameters where the value changes often (i.e., at least
> per-render), it is necessary to
> keep invoking the parent component's configure_foo() method (which has
> to be public, though that could be fixed).
Yes, that's what I have been saying. Configuration is a per-render
thing.
> So, what you're really saying is that people are going to prefer option A:
>
> <t:comp id="showProperties">
> ...
> <t:comp id="propLoop">
> <dt>${propertyName}</dt>
> <dd>${propertyValue}</dd>
> </t:comp>
> ...
> </t:comp>
>
> with
>
> public void configure_showProperties()
> {
> _showProperties.setTest(getShowPropertyList());
> }
>
> public void configure_propLoop()
> {
> _propLoop.setSource(getInfo().getPropertyNames());
> }
>
> to:
>
> <t:comp type="If" test="showPropertyList">
> ...
> <t:comp type="Loop" source="info.propertyNames" value="propertyName">
> <dt>${propertyName}</dt>
> <dd>${propertyValue}</dd>
> </t:comp>
> ...
> </t:comp>
>
> with
>
> ... nothing ...
Yes, I believe more Java users prefer option A especially when most of
the Java code in option A can be generated using a code template.
There is really no much more typing required, while we enjoy the
warm and fuzzy feeling of compile-time checking and auto-completion.
> I don't totally follow what is going on in terms of form support
> (though I think it could be implemented less obtrusively using
> ComponentActions and some code generation, and maybe some changes to
> FormSupport) but I'm finding some aspects of it a bit worrysome
> (particularily the fact that disabled is NOT re-evaluated on form
> submit).
The point about re-evaluating "disabled" is something that I haven't
been able to understand. If we render a field and decide that "disabled"
should be true, then on submission it should remain true, right?
Otherwise it will become inconsistent. If it must remain unchanged,
why re-evaluate it? Doing so will only give rise to inconsistence.
> I believe your value statement is that TypeSafe Tapestry makes the
> code more correct and more readable, allowing for IDE support in terms
> of available parameters (they are just setter methods) and parameter
> type.
Yes.
> I think you are correct, the code is more type safe, but does so by
> being more rigid.
I don't think it's more rigid. But that depends on what you mean by
rigid. Something that has gone in type safe Tapestry is that automatic
conversion of data to a required type. To do that now you must be
explicit about it. I think this is a case about explicit vs auto-magic.
I don't know how many Java programmers would prefer option A:
List list = ...;
if (list) {
...
}
to option B:
List list = ...;
if (!list.isEmpty()) {
...
}
Obviously the designers of Java didn't think so. In contrast, those of
PHP did. As our users are Java programmers, I tend to believe that they
prefer the Java way, not the PHP way.
> We've shifted more of the responsibility onto the
> developer and away from the framework.
I think this is not the case.
> This is true both for the
> author of the component (more setter and getter methods)
One can just choose "Source | Generate getters and setters". This is
hardly a burden. With the native property support in Java 7, this
won't even be required.
> and for the
> user of the component (the need for lots of configure_foo methods, the
> need to be aware of which are properties and which are bindings).
The configure_foo() methods are just replacements for the bindings.
There is hardly any difference in terms of effort required.
The component user is now clearly told which are properties and which
are bindings. In the past, they are not told about it but they must
still know about it (eg, to make sure the "value" binding points to
the right place on rewind)
> I think the templates suffer. They are less readable, more in service
> to the Java code and less readable (containing less useful
> information) than with parameter bindings in place.
I agree that putting the logic into templates makes the templates
easier to read, however, this is a maintenance nightmare: Do we
want JSP/ASP files that contain lots of Java code? Isn't that a
reason why people moved to MVC in Java and code-behind in .NET?
> In T3/T4 I found
> that too many users were not providing explciit ids for components, so
> T5 gives you a reward (don't have to bind value) and a better default
> id when the id is omitted (the component type in lower case). With
> TypeSafe, you must give each component, no matter how trivial, an
> explicit id in order to be able to configure its properties.
True. This is traded for the protection when we later rename the
property (refactor). The code will continue to work.
> There's some issues with flexibility. Component A renders component
> B, which has a parameter set from a property of component A. Inside
> B's body, there's a component C that modifies the property of A. When
> does B see that change? Not until it starts a completely fresh
> render. This kind of thing happens in more complex components, such as
> BeanEditFor and Grid (today) and the Ajax components coming in the
> future.
Then the parameter value should be a value source object, not the
value itself. As this is made explicit, the component user will know
that he can change it during rendering.
> There are performance issues (that could be addressed in non-prototype
> code). There are other performance issues (some of the form related
> stuff) that may be more difficult to address. Sorry, FUD ... slower
> than T5/trunk is not a peformance problem, just a difference.
Right.
> Where do we stop? Isn't the ${property} syntax just as questionable?
> It's not type safe (less important because it will always be converted
> into a string), but the same kind of refactoring changes that cause
> issues (addressed by TypeSafe Tapestry) will break property names in
> the templates, causing runtime exceptions.
I think making it ${id} may help. The Java code can be generated using
a simple code template.
If the property name is changed, it will still work.
If the id is changed in either the template or the Java file but not the
other side, then there will be a warning when the page is loaded (not as
good as compile time checking but slightly better than runtime exception).
> Lastly, there's the issue of compile time safety vs. working code.
> Code that compiles cleanly doesn't necessarily work. Testing is
> necessary on top of clean compiles. In the dynamic land, such as
> Ruby, code can be "untyped" and still industrial strength because they
> test the hell out of things. With your own contributions, plus
> Selenium, plus the clean POJO components, that is true for T5 as well
> ... fully, easily testable.
I agree that compile time checking doesn't mean the code is working.
In fact, I consider testing very critical in software development
(otherwise I wouldn't have worked on the PageTester). However, I
believe compile time checking is an important element in order to
efficiently produce working code. We all know that detects should
be detected and fixed as early as possible (the later it is fixed,
the more costly it gets, up to 100 times); Compile-time checking
exactly gives us that kind of early detection.
I agree that there are many people who prefer dynamic typed languages
(PHP, Ruby) to static typed languages (Java, C#). Just that I think
the targeted users of Tapestry use Java, they should prefer compile-
time checking.
> Further, with T5's ability to do extensive type coercions efficiently
> and invisibly, many of the changes necessitated by refactoring do go
> away.
I think the single most common reason for refactoring is the desire to
rename. Personally I seldom rename the type of fields.
> Finally, and this is much more subjective than the rest (which is
> already subjective), this just doesn't "feel" as much like Tapestry.
> All the other changes in T5 are just T4 with the chains removed.
> Souped up. Stream lined. Smarter defaults. Less code to accomplish the
> same thing. TypeSafe does more to change the basic nature of Tapestry
> than the new T5 code base does in an of itself.
As you noted, it may or may not seen as nature-changing:
1) In terms of effort, it took only a weekend to implement the type
safe feature. Everything still works. So, it is not a significant
change in this regard.
2) In your mind, I am sure it is a huge change. Personally I find it
is still Tapestry, just better. Everything else is there (component,
class transformation and reloading, life cycle, pooling, IoC). The
only thing changed is how to set the properties of a component.
3) From a recent post by a Tapestry committer on the server side, he
thought an advantage of Tapestry was its support for compile-time checking.
There are also people explicitly asking for compile-time checking on the
mailing list. So, for people like them, this is not something that will
destroy Tapestry, but make it better.
However, I think whether it is nature-changing is really unimportant.
The success of Tapestry is our goal. How to make it a success? It does
NOT depend on whether I like it or not. It solely depends on whether
our targeted users like it or not. It is unimportant that I find type
safe Tapestry better. It is important that we find out if our targeted
users find it better or not. That's all what I have been asking for.
It is an experiment. We should not trick people into believing that it is
here to stay. However, if all the reasons for accepting or rejecting it
is debatable (some people like it but some people don't), then not
giving them an opportunity to even take a look at is IMHO not in the
best interest of the project.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
