This just tells you the code that ran *after* the offending code. Which if
there are background process being fired by quartz for example, tells you
nothing.
I would suggest whipping together a proxy around the connection manager and
saving a exception (for it's stack trace) each time the code ha
I would hazard a guess that it would be useful to stop automated spam
entries in blogs and automated sign-up by robots.
anything that goes faster than a human could go could be throttled
On 1/27/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote
I'd love to know what your underlying us
Hi there --
I prefer the explicit "configure*" method approach for most of the reasons
mentioned by Kent in his original post, but also for these major reasons:
Reduced ramp-up time for a new developer
-
Under the current annotation app
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 fiel
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
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 p
I believe you could create a filter (in Tapestry 4) that could
intercept requests and work with a session-based object. The session
object would need to keep a list of timestamps of recent accesses.
With this, it could determine if a user has slipped over your
threshold, at which point you could,
How do you inject the current RequestContent for a client to a threaded
HivemindService?
Is there a way that ensures, that every client only accesses his own
RequestContext with this HivemindService that is then in return injected
into a page or component?
?
Thanks
hehe, great ren & stimpy reference..
2007/1/27, Jesse Kuhnert <[EMAIL PROTECTED]>:
No sir, I don't like it.
On 1/27/07, Kent Tong <[EMAIL PROTECTED]> wrote:
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. h
I find the annotation approach easier to grok. It's clearer as it
keeps all of the component configuration in a single (concise) place
in the code.
I agree with Martin that there should be a /single/ approach to
binding, not multiple.
I think consistency with the way that parameters are b
No sir, I don't like it.
On 1/27/07, Kent Tong <[EMAIL PROTECTED]> wrote:
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-
I would say, break the form to (probably) 3 different ones:
one before, one after and one *the* grid.
You could use a nasty approach and, when editting a row in your gread
using the EventListener component to clear all validation problems
recorded before. This will however not work for validati
No, leaving the decision up to the developer is not a solution at all.
Tapestry should have one proper way to do things and if someone is not
satisfied with it they can use a 3rd party lib that provides the
functionality they need. This will also reduce confusion for newcomers.
I'd prefer o l
Another rationale for the current approach is to keep control over the
lifecycle of the component.
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-ph
On 1/27/07, Hugo Palma <[EMAIL PROTECTED]> wrote:
I think both are valid options. In my opinion both ways should be
provided by the framework and it should be a developers decision to use
the one that fits his needs/taste.
For me, the issue is that this puts an onus on the developers (us!) to
On 1/27/07, Kent Tong <[EMAIL PROTECTED]> wrote:
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):
@
The problem is this:
when send an add new command I have this strange behavior:
the whole form is updated, but I want to update only the grid. How can I do?
A sipplet of the code here :
===
On 1/27/07, Andrea Chiumenti <[EMAIL
Thank you for your reply!
I've understood my mistake: it was that I set volatile to true in two places
I didn't have to.
Backing to the normal behavior now I can also provide the component without
its own form.
Now I have another question: How can I pervent the validation of components
outside
first, I would not in any cas try to write my own form component.
So, stale links:
In order for tapestry to submit a form, all form components must be
rendered on submit on the same order they were rendered for the response
which generated the form.
to make sure this happens, tapestry record
I think both are valid options. In my opinion both ways should be
provided by the framework and it should be a developers decision to use
the one that fits his needs/taste.
Question: what would happen if the developer configured the same
component both ways in the same page (by mistake or some
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
Since I'm not able to get off this stale link exception, I'm considering to
provide my edit grid with its own form component.
Dong so it will not be possible to put the edit grid inside a form component
(of course you can't put a inside another ).
I think that this trick will solve a lot of prob
Hello,
I'm using Tapestry 4.1.1 and I'm trying to update a comopnent.
This component is a grid, that in normal state hasn't any input component.
The first time i call addNew, that adds a new row with input elements all
goes well.
The next time i call this function I have a StaleLinkException.
wit
I was just wondering why Honeycomb creates a Core and a Web project for
Tapestry
To me a core is something that contains "Core" classes that can be reused in
other Web projects
However the created Core projects don't know anything about Tapestry, only the
Web project...so you can only
Hello,
Can ny one please tell/suggest me any site where in I can learn to develop
simple Ajax application in Tapestry.
With tacos components would be really gr8 help.
Thanks in advance
--
View this message in context:
http://www.nabble.com/Tapestry-Ajax-Application-tf3127642.html#a8665688
Sen
If I want to limit the number of clicks page views per second for every user,
how would I do that inside Tapestry?
Would that go into the BaseEngine ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [
Deprecated. To be removed in 4.1
protected ILink getLink(IRequestCycle cycle, String serviceName, Object
parameter)
What is the replacement for the method above?
Tanks!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
"To be removed in 4.1 with no direct replacement."
So what do you do with old Tapestry applications that use it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
28 matches
Mail list logo
