Re: Problem on Unit Testing Page containing SpringBean
Eko S.W. gmail.com> writes: > I've got problem on unit testing Tapestry Page using PageTester on T5. > If the page contain SpringBean, it cause Error : > getAttribute() is not supported Please see http://thread.gmane.org/gmane.comp.java.tapestry.user/46692 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: PageTester and Spring Integration
skipoles.co.uk> writes: > So, my question... is there a way that I can get spring integration working > within PageTester? If not, then some thoughts... You may want to create a feature request at https://issues.apache.org/jira/browse/TAPESTRY and upload a test case. There is no guarantee that it will be implemented though. -- 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]
Re: Starting with Tapestry
nilo de roock gmail.com> writes: > I don't know if the license permits, but I really hope Tapestry 4.1 will be > forked. The ideas in 5 are really cool and could be used as a vision for > developing 4.2 but in a slower pace perhaps and without breaking code. Yes > it will be more difficult, so what? The idea that T5 is coming too soon and existing code won't work in it sounds like a valid concern. However, if you think more about it, you may just hold off upgrading and wait until T5.1/T6 when you have received enough return on your investment on T3/T4 or when you start a new project? If there are enough people facing situations like you, then there will be a critical mass to maintain T4. The idea of creating a runtime compatibility layer sounds like an excellent idea. However, if you think more about it, given a working T4 applications, what do you gain by running it on this compatibility layer in T5? Instead, I think a better thing to do is to target those who are upgrading an existing T4 app to T5. 1) Create a migration tool that can automatically convert the source files to T5. It doesn't have to work 100% accurately, but should do the bulk of repetitive work in some limited scopes. 2) Create a platform that allows T4 pages and T5 pages running in the same app and create a bridge to allow them to communicate or to share ASO. -- Kent Tong 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]
Re: T5: which way do you prefer?
Howard Lewis Ship gmail.com> writes:
> Thing is, that would have to be
> _textField.setValidator("required,minlength=10").
>
> The way the validate binding factory works, it needs to know a lot
> about the component being bound as well as the container component.
> That's how it obtains the field's label (for presenting error
> messages), how it access's the containers catalog (to looks for
> approprately keyed messages),
The component should provide itself (or its ComponentResources) as
an argument to the check() method of FieldValidator. As this info
is supplied at the time of the call, we don't need to provide it
at construction time:
_textField.setValidator(new Required(), new MinLength(10));
This may allow us to pool and share validators (eg, "Required" as it
isn't bound to any particular component). Again, this is static structure,
dynamic behavior.
> and eventually, how it will provide an
> automatic default for the validators based on annotations on the
> setter method.
The component can determine default validators before rendering, also
based on the setter method. This logic can be extracted to a single
class, maybe even a mixin.
> 4) Less code when writing components. You just provide the field and
> access it freely.
> You don't have to worry about what's a simple property and what's a
> bi-directional parameter, they look the same to you.
I think with a bit of annotation and byte code generation, this can be
done for the type safe setter approach:
class TextField {
@Binding
private Object value;
private Validator validator;
}
> You don't have to
> worry about field converstions. You don't have to provide getter and
> setter methods (except for testing).
True. Those are trade-offs for compile time checking.
> Unless you provide a TypeCoercer from String to Color.
Again, trade off for compile time checking.
> > 4) Refactoring. If you rename a parameter, the calls to the setter will
> > be changed automatically.
>
> Though this will break existing code, whereas implementing T4's
> parameter aliases would allow existing code to work after an upgrade,
> with warnings.
For the code inside the same project, refactoring will work just fine.
For other code, there will be compile errors, which is a good thing
as it is tell us something is wrong.
The case about parameter alias is not really the same thing. I may
just rename a parameter during development because I found a better
name. I don't want to keep the old name around. If we really want
to achieve the same effect as parameter alias, we can just provide
a new setter and mark the old setter as deprecated, using the standard
Java mechanism. The warnings will be seen at compile time. It is also
easier for Java developers to understand.
> Javadoc with privates included can cover this. Perhaps some form of
> JavaDoc extension that omits privates, but includes Parameter fields.
Exactly what I was talking about. We need to devise new mechanisms to
do what the existing mechanisms in Java are doing fine.
> Component (parameters="validate=prop:myFieldSpecialValidator")
> private TextField _myField;
>
> public FieldValidator getMyFieldSpecialValidator()
> { return new FieldValidator() { ... } ; }
True, but this will not work when we need multiple validators. Yes,
I know about the $bean notation. This is another example of devising
new mechanisms for work that can already be done. All we need is to
provide a list of objects (validators) that has access to the field.
--
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]
Re: T5: which way do you prefer?
Howard Lewis Ship gmail.com> writes: > For me, the issue is that this puts an onus on the developers (us!) to > write much more code for components, while limiting their > functionality in the process (locking down some parameters as simple > read-only properties). Are you concerned that someone may change a parameter value when the component is rendering? > There's a lot of work involved in getting a parameter to work > properly, cache its value, reset at the end of the request, etc., > etc., that under the current system, is handled efficiently and > automatically with runtime bytecode generation. In the type safe setter style, the parameter values are cached in as properties. They are reset at the end of the request. The calls to the setter is compiled. What is missing? -- 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]
Re: T5: which way do you prefer?
Howard Lewis Ship gmail.com> writes: > T5 components have a very definite construction-phase (where they are > hooked up, parameters are bound, etc.) followed by a production-phase. > > The new methods you are talking about are contruction-phase only. But > what happens if they are invoked in production? The type safe setter style works in production. That is, the configuration of a component occurs in production (before it's rendered), after the component is constructed once (which does not include binding parameters to expressions to be evaluated later). > Case 1: the change is accepted and now this instance of this component > within this page instance behaves differently than any other instance, > which breaks down Principal 1: Static Structure, Dynamic Behavior. I don't think this is the case. A component instance in one page instance is exactly the same as others in other page instances. They all have their parameters (just properties) initialized to their default values. Before they're rendered, their containers need to set their properties. > Case 2: The code has to make a "locked down" check, which introduces a > new class of bugs where the check is omitted. I don't know why there needs a locked down check. Would you give an example? -- 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]
T5: which way do you prefer?
Hi,
In T5, how would like to configure a component? For example, let's imagine
a component type ColorText that outputs a string in a certain color. You're
now using this component in a page.
First, an all-binding style (same concept as in T4):
@ComponentClass
public class MyPage
{
@Component(parameters={"color=color", "text=literal:I am in red"})
private ColorText _colorText;
public Color getColor()
{
return Color.RED;
}
}
Alternatively, a type-safe setter style:
@ComponentClass
public class MyPage
{
@Component
private ColorText _colorText;
//This method will be called just before the component _colorText
//is rendered.
public void configureColorText()
{
_colorText.setColor(Color.RED);
_colorText.setText("I am in red");
}
}
This ColorText will not update any value on form submission so all we
need is to provide values to its parameters. If it was a TextField,
then the two approaches will be like:
The all-binding style:
@ComponentClass
public class MyPage
{
@Component(parameters={"value=name", "validator=required,minLength=10"})
private TextField _textField;
private String _name;
}
The type-safe setter style:
@ComponentClass
public class MyPage
{
@Component
private TextField _textField;
private String _name;
public void configureTextField()
{
_textField.setValueBinding("name"); //read and write
_textField.setValidator(new Required(), new MinLength(10));
...
}
}
So far, I've collected the following PROs and CONs for each approach.
The all-binding style:
1) Less typing.
2) Automatic data type conversion. For example, if a parameter is expecting
an Iterable, you can pass it a binding expression that returns an array.
Tapestry will automatically convert it to an Iterable.
3) Consistency across all parameters. They will use bindings no matter they
only read the value or perform read and write.
The type-safe setter style:
1) IDE auto-completion. The IDE will help you input the setters and the
parameter values.
2) Compile time parameter name checking. If you get the name of parameter
wrong, the call to the setter simply won't compile.
3) Compile time parameter value type checking. If you pass say a String to
setColor(), it simpy won't compile.
4) Refactoring. If you rename a parameter, the calls to the setter will
be changed automatically.
5) The Javadoc of the component class is the component doc. No need to devise
a new mechanism to write component doc.
6) Easier user level innovation. For example, if one would like to write
a new Validator, it's easier because it's just a Java class. With the all-
binding style, one will have to come up with a initializer syntax, register
it using a configuration under a validator name, while it's still limited
to having a single argument.
The above is just my observations. What's your take? Which one would you
use if both are available in T5?
--
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]
Re: Enjoying Web Development with Tapestry updated for T4.1 (with AJAX)
Daniel Jue wrote: Any discounts for those who ordered the online version about 6 months ago? About how many pages are dedicated to using AJAX with Tapestry? Well, the site says "Purchase a 1-year subscription" so you should get an email with the download link... Kent ? Yes, I did send the link to those valid subscribers a few days ago (supposedly including Daniel; I'll check). -- Kent Tong Useful & FREE software at http://www2.cpttm.org.mo/cyberlab/freeware - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANN: Enjoying Web Development with Tapestry updated for T4.1 (with AJAX)
Hi, I've updated my book for T4.1 with a new chapter on AJAX. The first four chapters are freely available. More info at http://www.agileskills2.org/EWDT Thanks! -- 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]
Re: new logo for Tapestry
Kent Tong cpttm.org.mo> writes: > I agree that a logo competition should be held. > > At the mean time, my artist friend has created one at > http://www.agileskills2.org/EWDT/Tapestry.jpg > > Please comment. My friend has made another one. Please go over http://www.agileskills2.org/EWDT/logos.html and comment! BTW, I was trying to list the unicorn one on my page too, but it seems to have appeared. Any idea? -- 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]
new logo for Tapestry
Hi, I agree that a logo competition should be held. At the mean time, my artist friend has created one at http://www.agileskills2.org/EWDT/Tapestry.jpg Please comment. -- Kent Tong 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]
Re: Testing pages
Rob Dennett tmit1.org> writes:
> Property bugService
> should be read-only; remove method public abstract void
> view.Browse.setBugService(model.services.BugService).
>
> How do you get around this?
Sorry that I've using this approach to unit test T3 pages only.
I don't know why @InjectObject should insist that the property is
read only if all it does is to define a getter. If this is not
absolutely necessary, you may extend InjectObjectWorker and override
its code:
public void injectObject(...)
{
Defense.notNull(op, "op");
Defense.notNull(propertyName, "propertyName");
Defense.notNull(objectReference, "objectReference");
Class propertyType = op.getPropertyType(propertyName);
if (propertyType == null)
propertyType = Object.class;
//op.claimReadonlyProperty(propertyName);
op.claimProperty(propertyName);
...
}
--
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]
Re: Testing pages
Rob Dennett wrote: My page uses an injected service to authenticate the user. The page only provides a getter. Do you add service setters to all your pages to provide hooks just for these setup pages? Yes. -- Kent Tong, Msc, MCSE, SCJP, CCSA, Delphi Certified Manager of IT Dept, CPTTM Authorized training for Borland, Cisco, Microsoft, Oracle, RedFlag & RedHat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tapestryforums.com
Jesse Kuhnert gmail.com> writes: > I think some agreement needs to be come to about tapestryforums.com. As we > receive a ~lot~ of spam from this service every day I'm less and less > enthusiastic about its continued operation. (at least as far as sending > emails to our users list goes) +1 -- Kent Tong 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]
Re: Testing pages
Rob Dennett wrote:
Since that is the case, how do you affect the services of a page?
For example, page 1 of my app is a login page. In order to get to
page 2, there needs to be a user in the database. I can fill in the
username and password fields on page 1 and click submit using
HtmlUnit, but it doesn't take me to page 2 because there is no data
in the database. I'd like to either get access to the database (I am
using an in-memory instance of HSQL for testing purposes) or give
page 1 a fake service which accepts the fake username and password
that HtmlUnit passes to it. Is there anyway to do that, or am I
totally misusing HtmlUnit?
Create a TestLoginPageCaller which is itself an external page. What
it does is to do something like:
void activateExternalPage() {
Login login = (Login)cycle.getPage("Login");
login.setUserAuthenticator(new UserAuthenticator() {
void authenticate(String userName, String passwd) {
//your fake implementation
}
});
cycle.activate(login);
}
--
Kent Tong, Msc, MCSE, SCJP, CCSA, Delphi Certified
Manager of IT Dept, CPTTM
Authorized training for Borland, Cisco, Microsoft, Oracle, RedFlag & RedHat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best way to record an error in a listener
Paul Cantrell pobox.com> writes:
> Ideally, I'd be able to do this:
>
> getPasswordField().recordError("Incorrect password");
>
> ...or something like that.
Try:
class ErrorRecord {
static void record(IFormComponent field, String msg) {
field.getForm().getDelegate().record(field, msg);
}
}
--
Kent Tong
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]
Re: problem with including external file as parameter
arun garg persistent.co.in> writes: > But the trouble is that if I make an asset and insert it, there are parsing > problems because one tag can not be > put inside another: > insert value="ognl.asset1">> Have you tried: -- Kent Tong 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]
Re: messages-encoding problem for japanese in utf-8?
Numa Schmeder euroconsumers.com> writes: > I have a problem localizing a tapestry application in japanese, a > translator has translated all properties file in japanese in utf-8, > so all the properties file are encoded in utf-8, opening thoses file > in eclipse or in a text editor that support utf-8 works great i can > see all japanese characters correctly. Then i set as specified in > the docs the property ' name="org.apache.tapestry.template-encoding_ja" value="UTF-8"/> ' in > my .application. > When i display a page in japanese i get cabalistic characters on my > web page like: Open your .html file in a browser and check what character set it is in. For example, in FireFox, choose View | Character Encoding to see which one is selected. I suspect your file is not in UTF-8. -- Kent Tong 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]
Re: Testing pages
Rob Dennett tmit1.org> writes: > Can you test your pages using HtmlUnit with mock services? I have a service > that is drawing data from the database and I would like to fake that for > testing purposes, but I can’t figure out how to do it. The way I do it is to create an XXXTestCaller external page to setup the fixture, call the page being tested and check the results. -- Kent Tong 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]
