Ol' Firebug tells me the autocomplete div looks like this:
So I guess you should be looking to CSS style-ise #countryName:menu or
.t-autocomplete-menu
Steve.
On 13 May 2010 23:48, Thiago H. de Paula Figueiredo wrote:
> On Fri, 14 May 2010 00:24:12 -0300, Paul Stanton
> wrote:
>
>> i've just
On Fri, 14 May 2010 00:43:02 -0300, Paul Stanton
wrote:
just further to that, i'm new to tapestry5 and haven't completed my
reading on ajax etc,
but how would i listen for the 'something selected from list' event (for
the autocomplete mixin), and do some asynchronous server side processi
On Fri, 14 May 2010 00:24:12 -0300, Paul Stanton
wrote:
i've just started using the autocomplete mixin after reading this demo:
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/javascript/autocompletemixin
one thing i'd like to change is how far away the search result div
ap
just further to that, i'm new to tapestry5 and haven't completed my
reading on ajax etc,
but how would i listen for the 'something selected from list' event (for
the autocomplete mixin), and do some asynchronous server side processing?
advice or direction to docs/articles appreciated!
thanks
i've just started using the autocomplete mixin after reading this demo:
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/javascript/autocompletemixin
one thing i'd like to change is how far away the search result div
appears from the input text. i'd like to reduce the gap to 0 pix
Can you post working code (.tml and .java) for chapter 4 of the tutorial on
working with forms?
I'm having trouble getting it to work and there is nowhere a listing of full
source - only snippets and pieces. The first 3 chapters had critical errors
in some of the snippets and caused me major gri
Can someone please post a copy of of all the .java .tml .properties files for
this chapter in the tutorial. The first tutorial was riddled with outdated
elements and bugs that caused much pain. I've now hit another road block
with this chapter and am hoping to head things off earlier this time r
I'm not doing that - Tapestry is when it adds zone support.
On 14/05/2010, at 10:54 AM, Paul Stanton wrote:
> just as an aside, you don't need to prefix your onclick with 'javascript:'
>
> Geoff Callender wrote:
>> > shape="rect" href="./simplewithzone:delete">Delete...
>>
>
> --
just as an aside, you don't need to prefix your onclick with 'javascript:'
Geoff Callender wrote:
Delete...
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...
On Thu, 13 May 2010 21:22:25 -0300, Geoff Callender
wrote:
shape="rect" href="./simplewithzone:delete">Delete...
I'm no JavaScript guru (very far from that, actually), but have you tried
setting onclick to null?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hi
I have a Confirm mixin that works fine until I put it in a zone. It still pops
up a confirmation dialog but when Cancel is pressed the mixin fails to stop the
event.
My mixin adds javascript that observes the element, but the zone seems to upset
it by adding javascript directly to the element,
- a bit off topic I know but...
I like "beforeRender()" and "afterRender()" for it's clear when they
occur and why. Whereas beginRender() and endRender() sound like
instructions - but onBeginRender() and onEndRender() on the other hand
are also very clear, if not more so... Hmm...
On 13 May 201
so, I just hope 5.2 is around the corner ...
Robert Zeigler wrote:
Thiago is right; it's more like a pipeline, although not exactly a pipeline, either. :)
It's still a state machine, stepping through the various render phases, but in each
render phase, you have a series of "sub states", one fo
Right. I'm simply pointing out a way to do that with mixins.
For instance, we can add:
@BindParamater;
private SelectModel model;
private BlankOption originalOption;
and make beginRender* look something like this
void beginRender() {
originalOption = blankOption;
if (blankOption == AUTO) {
On Thu, 13 May 2010 17:56:22 -0300, Benny Law
wrote:
Precisely. Thank you, Alex.
Mixins are excellent for some things, but not a replacement for
subclassing for every case.
I agree. There's a very hard balance between opening and keeping backward
compatibility.
And you have to add a
Thiago is right; it's more like a pipeline, although not exactly a pipeline,
either. :) It's still a state machine, stepping through the various render
phases, but in each render phase, you have a series of "sub states", one for
each mixin, + the component's own method. In 5.2, you can explicit
Precisely. Thank you, Alex.
Mixins are excellent for some things, but not a replacement for subclassing
for every case. And you have to add a bit of extra code per usage in the
.tml (t:mixin="...").
On Thu, May 13, 2010 at 4:20 PM, Alex Kotchnev wrote:
> I think it is fair to say that T5 has ind
this was the good roundup!
Andreas
Alex Kotchnev wrote:
I think it is fair to say that T5 has indeed gone to great lengths to try to
isolate the user from changes in the framework. Thus, if T5 decides to
change the internal implementation of how a Select works, there wouldn't be
100 people scre
very good roundup!
Everton Agner wrote:
If component classes were not meant to be subclassed, wouldn't it be nice to make them as
"final classes"?
It would not let people lose some time on it, since it would be seen at
compilation time, and it's kinda logical.
- Everton Agner Ramos
___
If component classes were not meant to be subclassed, wouldn't it be nice to
make them as "final classes"?
It would not let people lose some time on it, since it would be seen at
compilation time, and it's kinda logical.
- Everton Agner Ramos
De: Alex Kotc
I think it is fair to say that T5 has indeed gone to great lengths to try to
isolate the user from changes in the framework. Thus, if T5 decides to
change the internal implementation of how a Select works, there wouldn't be
100 people screaming "See, we told you that Tapestry has never been and wil
On Thu, 13 May 2010 17:09:45 -0300, Andreas Bohnert
wrote:
this looks very promising!!
that is what I was asking for and would solve at least my problem :)
So with mixins you do/can not override a method, you build a execution
chain instead?
In a simplified view, mixins work like you had
On Thu, 13 May 2010 16:48:07 -0300, Paul Stanton
wrote:
I assume you mean this bit:
--quote
Another way is to contribute objects that perform configuration (such as
setting event listeners). Example:
public static void
contributeHibernateSessionSource(OrderedConfiguration
config)
{
this looks very promising!!
that is what I was asking for and would solve at least my problem :)
So with mixins you do/can not override a method, you build a execution
chain instead?
Andreas
Robert Zeigler wrote:
Why are you wanting to change the "auto" behavior in the first place?
In the fe
Thanks Thiago,
I assume you mean this bit:
--quote
Another way is to contribute objects that perform configuration (such as
setting event listeners). Example:
public static void
contributeHibernateSessionSource(OrderedConfiguration
config)
{
config.add("Widget", new WidgetHibernateConfigur
hi all
i'm new to tapestry 5 and have started playing with tapestry-hibernate.
in other projects i've used an uncommon approach to configuring tapestry
whereby i load most of the configuration via hibernate.cfg.xml, but then
add a few more options via code and properties.
for example, the gener
On Thu, May 13, 2010 at 3:29 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Thu, 13 May 2010 15:44:50 -0300, Benny Law
> wrote:
>
> I want the user to consciously choose a value.
>>
>
> does
> the trick, no?
>
No, because I don't want the blank option if there is only one
On Thu, 13 May 2010 15:44:50 -0300, Benny Law
wrote:
I want the user to consciously choose a value.
does
the trick, no?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informaçã
> If the field is required, I still want a blank option
> unless there is exactly one option because I don't want the first option to
> be selected as a default. I want the user to consciously choose a value.
>
...wait. what? if it is required is probably not valid to choose the blank
option, r
...add some really heavy logic to your page/component:
tml:
page:
@Property
private String[] options;
@Persist
@Property
private String o;
@SetupRender
void setup() {
options = reallyExpe
As I explained before, I want to change the "auto" behavior to make it
smarter. Currently, there is really no intelligence in the logic: a blank
option is added if the field is not required, and no blank option is added
if the field is required. When the option list is static, I can set the
blank o
On Thu, 13 May 2010 15:30:11 -0300, Robert Zeigler
wrote:
In fact, this particular case could be handled (I think?) in 5.2 in a
very clean way.
I was thinking in a mixin too, but in 5.1 and using DOM rewriting. A
little more complicated, but still viable.
Or just bind the blankOption t
Why are you wanting to change the "auto" behavior in the first place?
In the few cases where there is no "sensible" default value, is using the
"blankLabel" and "blankOption" parameters so excruciatingly onerous? If so, why
not not simply wrap the select component in a custom select component tha
I did look at the demo Geoff posted. How is that going to provide what I
need? I'm sorry, but I fail to see this "easy fix" you mentioned. Maybe you
can be a bit more specific?
On Thu, May 13, 2010 at 1:15 PM, Christian Riedel
wrote:
> Well I agree that some more extensibility could be made here
Well I agree that some more extensibility could be made here and there. That
particular problem looks like it's worth a JIRA with a patch from you that
makes the component extensible to fix that problem :)
On the other hand there is an easy fix. Just look at the demo Geoff posted. Why
do you in
On Thu, 13 May 2010 08:22:46 -0300, Paul Stanton
wrote:
hi all
Hi!
i'm new to tapestry 5 and have started playing with tapestry-hibernate.
in other projects i've used an uncommon approach to configuring tapestry
whereby i load most of the configuration via hibernate.cfg.xml, but then
Thanks Geoff, but no, it doesn't. Your example shows how the Select
component works as is. What I need is a smarter interpretation of
BlankOption.AUTO. Basically, if you look at the showBlankOption() method in
the Select class, you see this:
switch (blankOption)
{
case
hi all
i'm new to tapestry 5 and have started playing with tapestry-hibernate.
in other projects i've used an uncommon approach to configuring tapestry
whereby i load most of the configuration via hibernate.cfg.xml, but then
add a few more options via code and properties.
for example, the ge
Does this help at all?
http://jumpstart.doublenegative.com.au/jumpstart/examples/select/varied/$N/$N/$N/$N
Cheers,
Geoff
On 14/05/2010, at 12:11 AM, Benny Law wrote:
> We are talking about subclassing a Tapestry component here. To give you an
> example, I wanted to subclass the Select
We are talking about subclassing a Tapestry component here. To give you an
example, I wanted to subclass the Select component to override how
BlankOption.AUTO is interpreted. I wanted the logic to not just look at the
required property but also to consider how many options are available and
whether
By the way, why that ?
Compatibility. The more open to subclassing a component is, the harder
it is to keep it backward-compatible.
Well, that's a good point. It's always about keeping the balance ...
Exactly. I was saying that components provided by Tapestry aren't
meant to
be subclass
On Thu, 13 May 2010 06:35:44 -0300, Nicolas Bouillon
wrote:
By the way, why that ?
Compatibility. The more open to subclassing a component is, the harder it
is to keep it backward-compatible.
It's one thing I felt difficult, for example to change the way the
GridPager is displayed (to
On Thu, 13 May 2010 09:58:15 -0300, Christian Riedel
wrote:
Why should you have the same rendering code in two different components?
When I have common code for several components I create an abstract base
component and put it into the base package. The template is not
mandatory for compone
Why should you have the same rendering code in two different components?
When I have common code for several components I create an abstract base
component and put it into the base package. The template is not mandatory for
components or abstract base components/pages btw. You can use subclassing
I also wish component subclassing was at least an option. What I don't like
about copying and pasting from a Tapestry component is that I end up relying
on some internal packages and classes. That makes me feel dirty.
Benny
On Thu, May 13, 2010 at 7:47 AM, Andreas Bohnert wrote:
> I agree.
> I
I agree.
I'm upgrading a big project from tapestry 3 to 5.
As I looked into the documentation and sources of tapestry 5 I thought:
wow, this is really great. it could not be any better!
But if components are no meant to be subclassed this seems like a
drawback for me. You have to copy and adju
Le 11/05/2010 21:34, Thiago H. de Paula Figueiredo a écrit :
1.) Extend MySelect from Select
I found no way to assign my model to the selects privat model. There
is a setModel in Select but it seems to be there only for unit tests.
Tapestry components weren't meant to be subclassed.
By the wa
47 matches
Mail list logo