Problem with AbstractAjaxTimerBehavior for periodic content update

[Tom Wollert <to...@googlemail.com>]

Hello there,

I have a website which needs quite frequent updating. I was using the
AbstractAjaxTimerBehavior for quite some time, with 1 second duration.
Worked fine on my working machine (dual core) but now on my home PC I
realized some problems. Firefox uses up a lot of CPU power apparently,
making other applications unresponsive (the working machine had apparently
only one coreused up, that's why I didnt notice the problem. My home PC only
has one core).

Anyway, I thought the AbstractAjaxTimerBehaviour was a stupid idea anyway,
but I need frequent updates (actually updates might be several seconds or
minutes apart, but if there are updates, they need to be displayed fast.

I had an idea to just answer the response whenever there is actually
something to update and then send the request back (or after a short
timeout, like 10 seconds). However I ran into another problem that ajax
calls from that website will be postponed, due to the ajax channel being
used. In effect, since my timeout is 10 seconds, resulting in a behaviour
similar to an AbstractAjaxTimerBehaviour with 10 seconds duration

Anyone has any ideas how to solve this problem?

- Tom

Re: HTML editing, HTML templates, HTML refactoring

[Jeremy Thomerson <je...@wickettraining.com>]

Suggest a solid approach to fix it and document on JIRA.

--
Jeremy Thomerson
http://www.wickettraining.com



On Tue, May 18, 2010 at 1:05 AM, <bh...@actrix.gen.nz> wrote:

> Yes:
>
> <wicket:link>
> <link rel='stylesheet' type='text/css' href='../../../../style.css'/>
> </wicket:link>
>
> WicketMessage: Exception in rendering component: [MarkupContainer
> [Component id = _link2]]
> Root cause:
>
> java.lang.IllegalArgumentException: Invalid path ../../../../style.css
>
> The path is valid because if I click on it in the IDE then the stle
> sheet is opened. I really want better IDE integration with Wicket, and
> I think that does not exist.
>
> https://issues.apache.org/jira/browse/WICKET-581
> ... you no longer need to use autolink. As of a couple of days ago in
> 1.3.0-incubating-SNAPSHOT, any href/src/whatever elements that are in
> your HTML will be prepended to make them context-relative, no matter
> where your page is mounted.
>
> Unfortunately, the intended result would not be satisfactory even
> without failure. I don't want to
> - have the wicket filter serve the resources
> - have the resources stored under WEB-INF/classes
>
> So I tried in init()
> getResourceSettings(addResourceFolder("wicket"));
>
> but that is where Wicket support ends because I still have to use
> <link rel='stylesheet' type='text/css' href='style.css'/> which works
> at runtime but not for any IDE for offline viewing and refactoring.
>
> Don't you think it would be time for Wicket to catch up with modern
> IDE HTML features? We can't use them.
>
> http://wicket.apache.org/
>
> Line 2:
>
> "With proper mark-up/logic separation ..."
>
> ?
>
> Not really.
>
>
> It works for the framework and component developers who want to bundle
> the resources with their packages, but it does not work for page
> development which has totally different requirements.
>
>
> Regards
>
> Bernard
>
>
> On Tue, 18 May 2010 00:21:24 -0500, you wrote:
>
> >Have you tried using wicket:link around your resource references?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: HTML editing, HTML templates, HTML refactoring

[bh...@actrix.gen.nz]

Yes:

<wicket:link>
<link rel='stylesheet' type='text/css' href='../../../../style.css'/>
</wicket:link>

WicketMessage: Exception in rendering component: [MarkupContainer
[Component id = _link2]]
Root cause:

java.lang.IllegalArgumentException: Invalid path ../../../../style.css

The path is valid because if I click on it in the IDE then the stle
sheet is opened. I really want better IDE integration with Wicket, and
I think that does not exist.

https://issues.apache.org/jira/browse/WICKET-581
... you no longer need to use autolink. As of a couple of days ago in
1.3.0-incubating-SNAPSHOT, any href/src/whatever elements that are in
your HTML will be prepended to make them context-relative, no matter
where your page is mounted.

Unfortunately, the intended result would not be satisfactory even
without failure. I don't want to
- have the wicket filter serve the resources
- have the resources stored under WEB-INF/classes

So I tried in init()
getResourceSettings(addResourceFolder("wicket"));

but that is where Wicket support ends because I still have to use
<link rel='stylesheet' type='text/css' href='style.css'/> which works
at runtime but not for any IDE for offline viewing and refactoring.

Don't you think it would be time for Wicket to catch up with modern
IDE HTML features? We can't use them.

http://wicket.apache.org/

Line 2:

"With proper mark-up/logic separation ..."

?

Not really.


It works for the framework and component developers who want to bundle
the resources with their packages, but it does not work for page
development which has totally different requirements.


Regards

Bernard


On Tue, 18 May 2010 00:21:24 -0500, you wrote:

>Have you tried using wicket:link around your resource references?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: HTML editing, HTML templates, HTML refactoring

[Jeremy Thomerson <je...@wickettraining.com>]

Have you tried using wicket:link around your resource references?

--
Jeremy Thomerson
http://www.wickettraining.com



On Tue, May 18, 2010 at 12:10 AM, <bh...@actrix.gen.nz> wrote:

> Jeremy,
>
> I am not asking for full previewbly in the sense that you are
> describing. Obviously this is not possible in dynamic scenarios.
>
> However, Dreamweaver provides templates where each panel can be
> previewed in the context of a page so it is Dreamweaver that provides
> full previewability. I have seen this documented at
>
> http://www.2rue.de/hacking/wicket/leveraging-wicket-templates-for-offline-viewing-with-dreamweaver/
>
> However, whether dynamic content can be previewed or not, it can
> always be filled with something that gets replaced at runtime anyway.
>
> In any case, I want to get the HTML resource paths right, so how do I
> do that? I haven't seen a solution for that yet.
>
> Many thanks,
>
> Bernard
>
>
> On Mon, 17 May 2010 23:52:59 -0500, you wrote:
>
> >You won't get full previewability in Wicket.  A page can have a panel that
> >is marked with <div wicket:id="myPanel">  That panel could be any panel at
> >runtime - and there'd be no way to preview the page with the panel in it
> >without running the app.
> >
> >I've seen teams successfully get their HTML designers to edit HTML in the
> >source tree if they were using Maven and could tell the designer to "cd
> >myproject; mvn jetty:run".
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: HTML editing, HTML templates, HTML refactoring

[bh...@actrix.gen.nz]

Jeremy,

I am not asking for full previewbly in the sense that you are
describing. Obviously this is not possible in dynamic scenarios.

However, Dreamweaver provides templates where each panel can be
previewed in the context of a page so it is Dreamweaver that provides
full previewability. I have seen this documented at
http://www.2rue.de/hacking/wicket/leveraging-wicket-templates-for-offline-viewing-with-dreamweaver/

However, whether dynamic content can be previewed or not, it can
always be filled with something that gets replaced at runtime anyway. 

In any case, I want to get the HTML resource paths right, so how do I
do that? I haven't seen a solution for that yet.

Many thanks,

Bernard


On Mon, 17 May 2010 23:52:59 -0500, you wrote:

>You won't get full previewability in Wicket.  A page can have a panel that
>is marked with <div wicket:id="myPanel">  That panel could be any panel at
>runtime - and there'd be no way to preview the page with the panel in it
>without running the app.
>
>I've seen teams successfully get their HTML designers to edit HTML in the
>source tree if they were using Maven and could tell the designer to "cd
>myproject; mvn jetty:run".


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: HTML editing, HTML templates, HTML refactoring

[Jeremy Thomerson <je...@wickettraining.com>]

You won't get full previewability in Wicket.  A page can have a panel that
is marked with <div wicket:id="myPanel">  That panel could be any panel at
runtime - and there'd be no way to preview the page with the panel in it
without running the app.

I've seen teams successfully get their HTML designers to edit HTML in the
source tree if they were using Maven and could tell the designer to "cd
myproject; mvn jetty:run".

--
Jeremy Thomerson
http://www.wickettraining.com



On Mon, May 17, 2010 at 11:37 PM, <bh...@actrix.gen.nz> wrote:

> Hi,
>
> IDE technology now offers HTML refactoring support even including css
> style selectors.
>
> Dreamweaver supports HTML remplates.
>
> In principle, Wicket could support these technologies due to its clean
> HTML approach.
>
> However, I have not been able to get any of this to work, because
> Wicket ignores its own Java package structure.
>
> I am prepared to do whatever is necessary, e.g. storing HTML page
> files outside Java packages. So far, if I do that, then I need to
> duplicate the Java package structure in the web directory. With that,
> all resource links e.g. images, css have to be "../../../..." for the
> web developers, but for Wicket they have to be "."
>
> So currently, refactoring does not work, and I have to copy every page
> into the web root for viewing.
>
> How can I provide the best editing experience for HTML developers so
> that all links work, and so that Dreamweaver templates and IDE
> refactoring are not broken?
>
>
> Many thanks,
>
> Bernard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

HTML editing, HTML templates, HTML refactoring

[bh...@actrix.gen.nz]

Hi,

IDE technology now offers HTML refactoring support even including css
style selectors.

Dreamweaver supports HTML remplates.

In principle, Wicket could support these technologies due to its clean
HTML approach.

However, I have not been able to get any of this to work, because
Wicket ignores its own Java package structure.

I am prepared to do whatever is necessary, e.g. storing HTML page
files outside Java packages. So far, if I do that, then I need to
duplicate the Java package structure in the web directory. With that,
all resource links e.g. images, css have to be "../../../..." for the
web developers, but for Wicket they have to be "."

So currently, refactoring does not work, and I have to copy every page
into the web root for viewing.

How can I provide the best editing experience for HTML developers so
that all links work, and so that Dreamweaver templates and IDE
refactoring are not broken?


Many thanks,

Bernard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org