JavaScript at the bottom of the page

2009-11-12 Thread Alex Parvulescu
hello,

I am looking at a thing that is common for most web development
performance-improving efforts: JavaScript at the bottom of the page.

The head merge features of the framework are very nice, but is there
anything that can help me with inserting the scripts at the bottom?
Anybody working on something that will do that gracefully?

I've found a issue on the Wicket Jira for a future version of Wicket,
but what can I do with 1.4?

any feedback is appreciated!

thanks,
alex

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



Re: wicket-spring classpath issue

2009-02-25 Thread Alex Parvulescu
Hello,

Your point is interesting , but I really think theres more to this than
simple convenience.

I am really interested in this because I think its a bug.

Its you choice if you want to have a big fat war (~5MB) and deploy that over
scp - i guess the fast deploy cycles go out the window,
or try to keep things small and easy , go with a common lib folder for all
the apps on the server and have ~300KB wars.

In the end I think that should be the developer's decision, and not be
constrained by an eventual bug in the framework. Apparently, the spring
beans get somehow shared by apps that have nothing in common, and thats not
good.

Thanks,
Alex

On Tue, Feb 24, 2009 at 6:32 PM, John Krasnay  wrote:

> IMHO sharing JARs across J2EE apps is not worth the trouble.
>
> - it messes up some JARs (commons-logging is a classic example)
>
> - it forces you to keep your dependent JAR versions in sync across
>  applications. This is particularly important in an enterprise
>  environment where changing a dependent JAR version may force an
>  additional QA cycle.
>
> - it complicates deployment, since you have to remember to put any new
>  dependent JARs in the app-server's lib directory instead of just
>  dropping the WAR in place.
>
> If you're like me, the memory allocated to the JVM is in the hundreds of
> megs, so an additional few megs in the WARs is simply not worth the
> effort.
>
> jk
>
> On Tue, Feb 24, 2009 at 04:00:58PM +0200, Alex Parvulescu wrote:
> > Hello,
> >
> > I have a problem with the wicket - spring integration in wicket 1.4 rc2 ,
> i
> > think its similar to https://issues.apache.org/jira/browse/WICKET-1848
> >
> > The use case is like this :
> >
> > I have 2 simple applications running in a jetty server.
> >
> > To keep things simple , i added the spring and wicket libs to the common
> > classpath (so the following libs: cglib-nodep-2.1_3.jar,
> > commons-logging-1.1.jar , log4j-1.2.13.jar , slf4j-api-1.5.0.jar ,
> > slf4j-log4j12-1.5.0.jar , spring-2.5.6.jar , wicket-1.4-rc2.jar ,
> > wicket-ioc-1.4-rc2.jar , wicket-spring-1.4-rc2.jar  go into
> > $JETTY_HOME/lib/ext/extra-libs )
> > That helps me keep the size of the wars lower.
> >
> > I think the problem is that by using this common classpath , the wicket
> > applications share -some- context.More to the point , I don't think that
> > LazyInitProxyFactory is thread safe , or maybe application safe. It
> appears
> > that bean ids from one application are visible in another application
> thats
> > deployed on the same server.
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


wicket-spring classpath issue

2009-02-24 Thread Alex Parvulescu
Hello,

I have a problem with the wicket - spring integration in wicket 1.4 rc2 , i
think its similar to https://issues.apache.org/jira/browse/WICKET-1848

The use case is like this :

I have 2 simple applications running in a jetty server.

To keep things simple , i added the spring and wicket libs to the common
classpath (so the following libs: cglib-nodep-2.1_3.jar,
commons-logging-1.1.jar , log4j-1.2.13.jar , slf4j-api-1.5.0.jar ,
slf4j-log4j12-1.5.0.jar , spring-2.5.6.jar , wicket-1.4-rc2.jar ,
wicket-ioc-1.4-rc2.jar , wicket-spring-1.4-rc2.jar  go into
$JETTY_HOME/lib/ext/extra-libs )
That helps me keep the size of the wars lower.

I think the problem is that by using this common classpath , the wicket
applications share -some- context.More to the point , I don't think that
LazyInitProxyFactory is thread safe , or maybe application safe. It appears
that bean ids from one application are visible in another application thats
deployed on the same server.

As an example : I can define a bean with the id 'simpleService' in the first
application. But when I try to define another bean in the second application
with the same id - still 'simpleService' but a different interface- I get
the following error:

GET, protocol = HTTP/1.1, requestURL = http://localhost:8080/, contentType =
null, contentLength = -1, contextPath = , pathInfo = null, requestURI = /,
servletPath = /, pathTranslated = null]
2009-02-24 15:08:04,803 ERROR org.apache.wicket.RequestCycle - Can't
instantiate page using constructor public com.asf.test2.web.Index()
org.apache.wicket.WicketRuntimeException: Can't instantiate page using
constructor public com.asf.test2.web.Index()
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:172)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1192)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1271)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1370)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:501)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:455)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:288)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:865)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:538)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:153)
... 28 more
Caused by: java.lang.RuntimeException: error while injecting object [[Page
class = com.asf.test2.web.Index, id = 0, version = 0]] of type
[com.asf.test2.web.Index]
at org.apache.wicket.injection.Injector.inject(Injector.java:118)
at
org.apache.wicket.injection.ConfigurableInjector.inject(Configura

htmlunit error

2008-12-17 Thread Alex Parvulescu
Hello,

i am currently in the process of writing some tests for an app.
I am using wicket 1.3.4 and html-unit 2.3

this is about a functional test involving an ajax heavy page with a modal
window (open / close ), ajax refreshing parts (both in the modal and in the
main page),

it seems that for long running tests (a few minutes long) it get the error

[junit]com.gargoylesoftware.htmlunit.JavaScriptBackgroundJob - Caught
exception in Window.setTimeout().
[junit] === EXCEPTION START 
[junit] EcmaError: lineNumber=[1] column=[0] lineSource=[]
name=[ReferenceError] sourceName=[JavaScriptBackgroundJob]
message=[ReferenceError: "Wicket" is not defined.
(JavaScriptBackgroundJob#1)]
[junit] com.gargoylesoftware.htmlunit.ScriptException: ReferenceError:
"Wicket" is not defined. (JavaScriptBackgroundJob#1)
[junit] at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:528)
[junit] at org.mozilla.javascript.Context.call(Context.java:502)
[junit] at
org.mozilla.javascript.ContextFactory.call(ContextFactory.java:511)
[junit] at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:405)
[junit] at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:380)
[junit] at
com.gargoylesoftware.htmlunit.html.HtmlPage.executeJavaScriptIfPossible(HtmlPage.java:890)
[junit] at
com.gargoylesoftware.htmlunit.JavaScriptBackgroundJob.run(JavaScriptBackgroundJob.java:101)

Has anyone seen this before?

I don't know if its a html-unit problem or not.I for one think its is
,mainly because of the way it handles ajax, but my tests are failing and
that doesn't help me push the 'functional testing is good' idea.I'm pretty
much stuck.

Any help would be appreciated!

Thank you,
Alex


Re: datatable and access to toolbars

2008-11-23 Thread Alex Parvulescu
Hello,

Your solution is good, I actually did that, but it does not cover all the
use cases.A toolbar can replace itself with another toolbar, but I need
external access to the toolbars, from the hierarchy.
For example, each table row has an 'edit' button, on click, I need the
'edit' toolbar to appear/activate.

My problem is that I can't reach the toolbar component with a simple
table.get(DataTable.TOOLBAR_COMPONENT_ID) .

I think I'll roll my own, as Igor suggested,

Thank you very much!
Alex

On Sun, Nov 23, 2008 at 4:10 PM, James Carman <[EMAIL PROTECTED]>wrote:

> How about you have your toolbar replace its own contents based on what
> "mode" it's in?
>
> On Sun, Nov 23, 2008 at 7:59 AM, Alex Parvulescu
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> > Perhaps i did not make myself clear,
> >
> > After adding the toolbar , i need to replace it with another toolbar.
> >
> > Let's say that I have an 'add new' toolbar - with only an 'add new'
> button,
> > and an 'edit' toolbar, for the editing part.
> >
> > The user clicks 'add new' - the 'add new' toolbar is replaced with the
> > 'edit' toolbar. on ok , the 'edit' toolbar is replaced again with the
> 'add
> > new' toolbar.A simple CRUD editor, embedded in the datatable component.
> >
> > That's why i need a way to reach the toolbar through the api, maybe
> through
> > the #get method (something like table.get(DataTable.TOOLBAR_COMPONENT_ID)
> )
> >
> > It seems that after adding a toolbar to a table, there is no way that you
> > can reach it in the component hierarchy anymore.
> >
> > Thanks,
> > Alex
> >
> > On Fri, Nov 21, 2008 at 5:49 PM, Igor Vaynberg <[EMAIL PROTECTED]
> >wrote:
> >
> >> see #addbottomtoolbar()
> >>
> >> -igor
> >>
> >> On Fri, Nov 21, 2008 at 2:57 AM, Alex Parvulescu
> >> <[EMAIL PROTECTED]> wrote:
> >> > Hello,
> >> >
> >> > i have a question about the toolbars in the DataTable component.
> >> >
> >> > my use case is this : i want to embed a small editor in a bottom
> >> toolbar.Its
> >> > a simple ok / cancel panel.
> >> >
> >> > I see that there no access to the 'bottomToolbars' variable in the
> >> DataTable
> >> > its private and final and has no accessors.
> >> >
> >> > Plus theres no way i can replace a toolbar, if i try
> >> > table.get(DataTable.TOOLBAR_COMPONENT_ID) the result is null,
> >> > another approach is table.replace(new EditToolbar(table)); - which
> >> outputs
> >> > an error: org.apache.wicket.WicketRuntimeException: Cannot replace a
> >> > component which has not been added: id='toolbar'...
> >> >
> >> > My guess is that this is because of the   DataTable#addToolbar method:
> >> > toolbar.setRenderBodyOnly(true); ..
> >> >
> >> > I have no workaround for this , except to drop the toolbars and start
> new
> >> > with some panels.
> >> >
> >> > My question is if theres a reason toolbars are hidden away from the
> user,
> >> > theres no clear way of working with them, except to initialise, and
> them
> >> let
> >> > them be.
> >> >
> >> >
> >> > btw i am using wicket 1.3.4
> >> >
> >> > thanks,
> >> >
> >> > Alex
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


Re: datatable and access to toolbars

2008-11-23 Thread Alex Parvulescu
Hi,
Perhaps i did not make myself clear,

After adding the toolbar , i need to replace it with another toolbar.

Let's say that I have an 'add new' toolbar - with only an 'add new' button,
and an 'edit' toolbar, for the editing part.

The user clicks 'add new' - the 'add new' toolbar is replaced with the
'edit' toolbar. on ok , the 'edit' toolbar is replaced again with the 'add
new' toolbar.A simple CRUD editor, embedded in the datatable component.

That's why i need a way to reach the toolbar through the api, maybe through
the #get method (something like table.get(DataTable.TOOLBAR_COMPONENT_ID) )

It seems that after adding a toolbar to a table, there is no way that you
can reach it in the component hierarchy anymore.

Thanks,
Alex

On Fri, Nov 21, 2008 at 5:49 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote:

> see #addbottomtoolbar()
>
> -igor
>
> On Fri, Nov 21, 2008 at 2:57 AM, Alex Parvulescu
> <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > i have a question about the toolbars in the DataTable component.
> >
> > my use case is this : i want to embed a small editor in a bottom
> toolbar.Its
> > a simple ok / cancel panel.
> >
> > I see that there no access to the 'bottomToolbars' variable in the
> DataTable
> > its private and final and has no accessors.
> >
> > Plus theres no way i can replace a toolbar, if i try
> > table.get(DataTable.TOOLBAR_COMPONENT_ID) the result is null,
> > another approach is table.replace(new EditToolbar(table)); - which
> outputs
> > an error: org.apache.wicket.WicketRuntimeException: Cannot replace a
> > component which has not been added: id='toolbar'...
> >
> > My guess is that this is because of the   DataTable#addToolbar method:
> > toolbar.setRenderBodyOnly(true); ..
> >
> > I have no workaround for this , except to drop the toolbars and start new
> > with some panels.
> >
> > My question is if theres a reason toolbars are hidden away from the user,
> > theres no clear way of working with them, except to initialise, and them
> let
> > them be.
> >
> >
> > btw i am using wicket 1.3.4
> >
> > thanks,
> >
> > Alex
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


datatable and access to toolbars

2008-11-21 Thread Alex Parvulescu
Hello,

i have a question about the toolbars in the DataTable component.

my use case is this : i want to embed a small editor in a bottom toolbar.Its
a simple ok / cancel panel.

I see that there no access to the 'bottomToolbars' variable in the DataTable
its private and final and has no accessors.

Plus theres no way i can replace a toolbar, if i try
table.get(DataTable.TOOLBAR_COMPONENT_ID) the result is null,
another approach is table.replace(new EditToolbar(table)); - which outputs
an error: org.apache.wicket.WicketRuntimeException: Cannot replace a
component which has not been added: id='toolbar'...

My guess is that this is because of the   DataTable#addToolbar method:
toolbar.setRenderBodyOnly(true); ..

I have no workaround for this , except to drop the toolbars and start new
with some panels.

My question is if theres a reason toolbars are hidden away from the user,
theres no clear way of working with them, except to initialise, and them let
them be.


btw i am using wicket 1.3.4

thanks,

Alex