On Wed, 05 Feb 2014 17:28:23 -0200, Lance Java
wrote:
I'm not suggesting the javascript request should be stateless. The lag
between the two requests means the db can be in an inconsistent state
between the two requests and the markup doesn't match the javascript.
For this to work the js and
I'm not suggesting the javascript request should be stateless. The lag
between the two requests means the db can be in an inconsistent state
between the two requests and the markup doesn't match the javascript.
For this to work the js and markup need to be authored in the same request.
I would agree. I think the state should be in the URL. I also think it
should be implemented like an event link with a zone response not a cache.
That allows the developer to store the state just like any other event
link.
On Wednesday, February 5, 2014, Lance Java
wrote:
> > The reason I wrot
I think this is about being able to scroll horizontally int he browser
and yet keeping the first 2 columns on the screen, as described here:
http://stackoverflow.com/questions/1312236/how-do-i-create-an-html-table-with-fixed-frozen-left-column-and-scrollable-body
But since the Tapestry Grid
2014-02-05 Wasaj Wasd :
> I want to freeze first 2 columns in grid. How I can do this in Tapestry5.3?
What do you mean by "freeze"? Disabled sorting? Another kind of style?
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apa
Hi.
I want to freeze first 2 columns in grid. How I can do this in Tapestry5.3?
About ideas and opportunities I am pleased.
> The reason I wrote the session cache was to support clustering.
I'm against the idea of forcing a session to support this.
> Well, we would solve the original request and Tapestry would be able to
tell it's optionally CSP-compliant out of the box
I'm not sure that it would be CSP compliant since I'm sure there's an
eval() in the js somewhere for ajax responses.
IMHO all javascript functions should be defined in static, cacheable js
files.
The inline scripts are just for passing dynamic arguments to functions
defined in static scripts.
On Wed, 05 Feb 2014 11:37:36 -0200, Lance Java
wrote:
But would we actually be solving anything? Or are we just ticking a box
:)
:D Well, we would solve the original request and Tapestry would be able to
tell it's optionally CSP-compliant out of the box. It would take a couple
hours t
The reason I wrote the session cache was to support clustering. The data
uri would solve that problem also. Before data attributes I found it useful
because it made some things much simpler than the Tapestry 5.3 way of doing
things. Since you can put scripts in the tml file you can use properties t
But would we actually be solving anything? Or are we just ticking a box :)
On 5 Feb 2014 13:34, "Thiago H de Paula Figueiredo"
wrote:
> On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java
> wrote:
>
> Any thoughts on using a data uri?
>>
>
> Good catch, Lance. Supposing browsers support it, and I d
On Wed, 05 Feb 2014 11:26:11 -0200, Lance Java
wrote:
Any thoughts on using a data uri?
Good catch, Lance. Supposing browsers support it, and I don't know the
answer, it would be the ideal solution.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
h
Any thoughts on using a data uri?
http://en.m.wikipedia.org/wiki/Data_URI_scheme
On 5 Feb 2014 13:13, "Lance Java" wrote:
> Another consideration with the token approach is clustering. Either a
> sticky session or a distributed cache are required.
>
Another consideration with the token approach is clustering. Either a
sticky session or a distributed cache are required.
I wrote a javascript cache for tapestry5-jquery a few years ago
https://github.com/got5/tapestry5-jquery/tree/master/src/main/java/org/got5/tapestry5/jquery/services/js
oddly enough I wrote it so you could use inline javascript in a tml file
with zones. I believe I created a couple of implementat
does t5's form generation hmac stuff lend itself to this non predictable
task?
Digressing a bit,
A log would show nuisances taking guesses. At the extreme scale of
sensitive info and network architecture, the cat can be skinned at the
network(ing layer).
On 05/02/2014 10:06 pm, "Lance Java" wro
On Wed, 05 Feb 2014 06:59:23 -0200, Kristian Marinkovic
wrote:
i also think it's up to the development team to decide how they want to
develop (inline-scripts vs. no inline-scripts). sometimes inline-scripts
make things easier. having a choice is good anyways.
still, do you think it is worth
If we were to use a token, care would need to be taken with token
generation such that it's not predictable. We don't want hackers
intercepting sensitive data meant for another client.
Chris, I was beginning to think along the same lines.
A configuration symbol (boolean) to choose either an inline script or an
extra (page specific) js import using the token + time to live strategy
sounds like a good solution to me.
Just to poke my uninformed and long-worked-days nose in, I reckon if a bit
of sample code that did this caching (and may i chime in, and perhaps
allowed for a tapestry configuration symbol to enable/disable this
behaviour) were to magically be attached to a jira, then the likelihood of
it being con
i also think it's up to the development team to decide how they want to
develop (inline-scripts vs. no inline-scripts). sometimes inline-scripts
make things easier. having a choice is good anyways.
still, do you think it is worth moving the requriejs specific
inline-scripts into a dynamically gene
Kristian, I'm still not sure you get the need for the inline script /
JavaScriptSupport.
Let's consider a Google map component with markers on it.
With inline scripts, we can include the empty div and the markers in a
single request.
Without inline scripts you would need to either:
1. Include t
looking at my migrated Tapestry 5.4-beta-2 app i can only see two inline
scripts. The requirejs configuration (shim, ...) and the require call
itself.
Is it possible to move those into a dynamically generated js instead,
that's included with a script tag? the requirejs config could by cached.
And
24 matches
Mail list logo
