RE: Single Page Applications (SPA), Wicket and the history ajax back issue

[Anup Gokhale]

Hi.

Even I am struggling with similar issues. A demo app would definitely go a long 
way in sorting this out.

Regards,

Anup

-Original Message-
From: Martin Grigorov [mailto:martin.grigo...@gmail.com]
Sent: 08 July 2016 03:59
To: users@wicket.apache.org
Subject: Re: Single Page Applications (SPA), Wicket and the history ajax back 
issue

Hi,

It seems you use Wicket for several years now and you have no idea how to use 
it!

On Jul 7, 2016 3:13 PM, "Wayne W"  wrote:
>
> Hi Sven,
>
> of course: Ok so this is simplified somewhat: lets say we have 4 main
> tab areas of the application: Contacts, Files, Calendar, Tasks. When a
> user navigates from one area to the next we need to currently do a
> whole page refresh, where in fact all we really need to do is refresh
> a sub panel via

This is a no-brainer with Wicket Ajax.

> ajax. This already is more 'old school' as I put it in the fact the
> user experiences the whole page refreshing rather than say a
> loading/spinner in the main panel. We want to make the web pp fell
> more 'app like' rather
than
> a succession of web pages. Another example is say we are in the "File"
> tab and we want to drill down through some folders, at the moment we
> need to refresh the page if we want to support the back button rather
> than load
via
> ajax.

I have done this for a client of mine 4 years ago.
And I have explained how to do it few times in the mailing lists.
You could use HTML5 History API to manipulate the browser url on each Ajax 
call. If you need to support old browsers (why?! almost no one does these
days) then you should use some JS library that falls back to using the location 
fragment/hash.
The support of "back/forward" buttons is just registering an AjaxEventBehavior 
that listens for "popState"/"hashchange" event.

>
> It just gives a much less slick experience as the page reloads
> visually, and there is more data sent over the wire - slower page
> loads. But ultimately it about the users impression of the app and
> feeling like an
app
> rather than a bunch of pages.

I will try to find time to write a blog article with a demo app at 
wicketinaction.com soon.

>
>
> On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier  wrote:
>
> > Hi,
> >
> > it would be interesting to hear what limitations you're fighting
against.
> > As a server-side rendered framework Wicket surely isn't the new kid
> > on
the
> > block, but I can't think of anything forcing your application to be
> > 'old school'.
> >
> > Can you be more specific?
> >
> > Sven
> >
> >
> >
> > Am 7. Juli 2016, 13:23, um 13:23, Wayne W
> > 
> > schrieb:
> > >Hi,
> > >
> > >we're been using wicket for some time now and we have a very
> > >established application used by many clients. It is however feeling
> > >some what dated, due to the fact the we have to constantly reload
> > >pages to access different functionality/areas if the app. We use
> > >ajax fairly heavily within each functional area.
> > >
> > >The problem is we are starting to 'feel' old school and we're
> > >loosing out to the competition that are based on the lasted SPA
> > >type JS frameworks talking to APIs. They just feel more slick and
> > >more responsive.
> > >
> > >Doing some research it seems thats it not possible to transform our
> > >current wicket app into this form, mainly due to the issues around
> > >wicket ajax state storage and history URL support in older
> > >browsers.
> > >
> > >Is this something the Wicket is never going to to attempt to
> > >support? I cannot find anything around this subject.
> > >
> > >Having a huge investment in our Wicket based application, its going
> > >to be very very painful to move away from which we must do if we
> > >cannot keep up with the competition due to framework limitations.
> > >
> > >many thanks
> >


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Martin Grigorov]

Hi,

It seems you use Wicket for several years now and you have no idea how to
use it!

On Jul 7, 2016 3:13 PM, "Wayne W"  wrote:
>
> Hi Sven,
>
> of course: Ok so this is simplified somewhat: lets say we have 4 main tab
> areas of the application: Contacts, Files, Calendar, Tasks. When a user
> navigates from one area to the next we need to currently do a whole page
> refresh, where in fact all we really need to do is refresh a sub panel via

This is a no-brainer with Wicket Ajax.

> ajax. This already is more 'old school' as I put it in the fact the user
> experiences the whole page refreshing rather than say a loading/spinner in
> the main panel. We want to make the web pp fell more 'app like' rather
than
> a succession of web pages. Another example is say we are in the "File" tab
> and we want to drill down through some folders, at the moment we need to
> refresh the page if we want to support the back button rather than load
via
> ajax.

I have done this for a client of mine 4 years ago.
And I have explained how to do it few times in the mailing lists.
You could use HTML5 History API to manipulate the browser url on each Ajax
call. If you need to support old browsers (why?! almost no one does these
days) then you should use some JS library that falls back to using the
location fragment/hash.
The support of "back/forward" buttons is just registering an
AjaxEventBehavior that listens for "popState"/"hashchange" event.

>
> It just gives a much less slick experience as the page reloads visually,
> and there is more data sent over the wire - slower page loads. But
> ultimately it about the users impression of the app and feeling like an
app
> rather than a bunch of pages.

I will try to find time to write a blog article with a demo app at
wicketinaction.com soon.

>
>
> On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier  wrote:
>
> > Hi,
> >
> > it would be interesting to hear what limitations you're fighting
against.
> > As a server-side rendered framework Wicket surely isn't the new kid on
the
> > block, but I can't think of anything forcing your application to be 'old
> > school'.
> >
> > Can you be more specific?
> >
> > Sven
> >
> >
> >
> > Am 7. Juli 2016, 13:23, um 13:23, Wayne W 
> > schrieb:
> > >Hi,
> > >
> > >we're been using wicket for some time now and we have a very
> > >established
> > >application used by many clients. It is however feeling some what
> > >dated,
> > >due to the fact the we have to constantly reload pages to access
> > >different
> > >functionality/areas if the app. We use ajax fairly heavily within each
> > >functional area.
> > >
> > >The problem is we are starting to 'feel' old school and we're loosing
> > >out
> > >to the competition that are based on the lasted SPA type JS frameworks
> > >talking to APIs. They just feel more slick and more responsive.
> > >
> > >Doing some research it seems thats it not possible to transform our
> > >current
> > >wicket app into this form, mainly due to the issues around wicket ajax
> > >state storage and history URL support in older browsers.
> > >
> > >Is this something the Wicket is never going to to attempt to support? I
> > >cannot find anything around this subject.
> > >
> > >Having a huge investment in our Wicket based application, its going to
> > >be
> > >very very painful to move away from which we must do if we cannot keep
> > >up
> > >with the competition due to framework limitations.
> > >
> > >many thanks
> >

Re: JQuery 3.0.0

[Martin Grigorov]

Yes! Both latest versions of 1.x and 2.x are fine!
On Jul 7, 2016 9:22 PM, "Boris Goldowsky"  wrote:

> OK, thanks.  From the release notes it sounds like 2.2.3 at least should
> be safe to use?
>
> Boris
>
>
> On 7/7/16, 1:38 PM, "Martin Grigorov"  wrote:
>
> Hi,
>
> Yes, there are known problems.
> It is not recommended to upgrade yet!
> On Jul 7, 2016 8:25 PM, "Boris Goldowsky"  wrote:
>
> > Are there any problems with replacing the default jQuery reference in
> > Wicket 7.3 (jQuery 1.12.3) with the latest (jQuery 3.0.0)?  Have others
> > tried this configuration?
> >
> > Thanks
> >
> > Boris
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: JQuery 3.0.0

[Boris Goldowsky]

OK, thanks.  From the release notes it sounds like 2.2.3 at least should be 
safe to use?

Boris


On 7/7/16, 1:38 PM, "Martin Grigorov"  wrote:

Hi,

Yes, there are known problems.
It is not recommended to upgrade yet!
On Jul 7, 2016 8:25 PM, "Boris Goldowsky"  wrote:

> Are there any problems with replacing the default jQuery reference in
> Wicket 7.3 (jQuery 1.12.3) with the latest (jQuery 3.0.0)?  Have others
> tried this configuration?
>
> Thanks
>
> Boris
>
>



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

Re: JQuery 3.0.0

[Martin Grigorov]

Hi,

Yes, there are known problems.
It is not recommended to upgrade yet!
On Jul 7, 2016 8:25 PM, "Boris Goldowsky"  wrote:

> Are there any problems with replacing the default jQuery reference in
> Wicket 7.3 (jQuery 1.12.3) with the latest (jQuery 3.0.0)?  Have others
> tried this configuration?
>
> Thanks
>
> Boris
>
>

JQuery 3.0.0

[Boris Goldowsky]

Are there any problems with replacing the default jQuery reference in Wicket 
7.3 (jQuery 1.12.3) with the latest (jQuery 3.0.0)?  Have others tried this 
configuration?

Thanks

Boris

Tool for finding missing translations in properties.xml

[Thorsten Schöning]

Hi all,

in my Wicket app I'm using properties.xml files for my i18n texts,
like described in the wiki[1]. The problem I have is that the files
are differently up to date, depending on the language and how
important it was for somebody to translate one exact key for one
special language etc. the only thing I really know is that English is
up to date...

So, does anyone knows a tool which expects translation files in a dir
structure and compares all found to their English base file? In the
end it should simply print which file in which dir is missing which
key compared to the English base.

Such a problem sounds common to me, but I couldn't find any good
software dealing with it yet.

Thanks!

[1]: https://ci.apache.org/projects/wicket/guide/6.x/guide/i18n.html#i18n_2

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


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

Re: Style Sheet in page head

[Peter Henderson]

On Thu, Jul 7, 2016 at 2:02 PM, Francois Meillet  wrote:

> If you look at what is sent by Wicket   (open the Wicket Ajax Debug panel
> or use a debugging proxy like Charles Proxy),
> you will see
>
>
> 
> 
> 
> 
> 
> 
> 
> 
>
>
> The id and type with null value are just extrapolated and added by tools
> (firebugs and so on), but are not in the html page.
>

Beautiful.

The wicket server side code creates the correct response. The problem lies
in
wicket-ajax-jquery.js line 2121

// copy required attributes
css.id = node.getAttribute("id");
css.rel = node.getAttribute("rel");
css.href = node.getAttribute("href");
css.type = node.getAttribute("type");

// add element to head
Wicket.Head.addElement(css);

This code assumes the header item has attributes "id" and "type" and
blindly adds them to the new DOM.

Thanks François







> François
>
>
>
> > Le 7 juil. 2016 à 13:12, Peter Henderson 
> a écrit :
> >
> > Thanks François
> >
> >
> >
> > On Thu, Jul 7, 2016 at 11:51 AM, Francois Meillet <
> > francois.meil...@gmail.com > wrote:
> >
> >> You don't define id and type so there are null.
> >>
> >> just add id="yourid" type="text/css"
> >>
> >> 
> >>  
> >> 
> >>
> >>
> > Although MDN shows examples without an id or type [1].
> > The examples shown by the  html5 standards [2] page also don't have type
> > and id for style sheets.
> >
> >
> >
> > [1]
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#Examples <
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#Examples>
> > [2]https://www.w3.org/TR/html5/document-metadata.html#the-link-element <
> https://www.w3.org/TR/html5/document-metadata.html#the-link-element>
> >
> >
> >
> >
> >> François
> >>
> >>
> >>
> >>> Le 7 juil. 2016 à 12:24, Peter Henderson 
> >> a écrit :
> >>>
> >>> Hello,
> >>>
> >>>
> >>> I might have found a small bug.
> >>>
> >>> I have a control which has a style sheet link in its head section.
> >>> This control is used within a ListView but is initially hidden.
> >>> An ajax action causes the control to become visible.
> >>>
> >>> The style sheet link added to the page head looks malformed.
> >>>
> >>> 
> >>> 
> >>> 
> >>>
> >>> Full page reload corrects the header link.
> >>>
> >>> 
> >>> 
> >>> 
> >>>
> >>> Am I doing something wrong or is this a bug?
> >>>
> >>>
> >>> I've created a quick start which is available
> >>> https://github.com/bollinger/wicket-style-bug
> >>>
> >>>
> >>> Thanks
> >>>
> >>> --
> >>> Peter Henderson
> >>>
> >>> Director
> >>> Starjar Ltd.
> >>> www.starjar.com
> >>> 0330 088 1662
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org  users-unsubscr...@wicket.apache.org>
> >> For additional commands, e-mail: users-h...@wicket.apache.org  users-h...@wicket.apache.org>
> >>
> >>
> >
> >
> > --
> > Peter Henderson
> >
> > Director
> > Starjar Ltd.
> > www.starjar.com 
> > 0330 088 1662
>
>


-- 
Peter Henderson

Director
Starjar Ltd.
www.starjar.com
0330 088 1662

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Sven Meier]

Hi,

> navigates from one area to the next we need to currently do a whole 
page refresh
> drill down through some folders, at the moment we need to refresh the 
page


both are common cases for Wicket's Ajax updates.

> if we want to support the back button rather than load via ajax

So you don't use Ajax because of missing back button support?
We have a feature request for that, but it didn't spark much interest:

https://issues.apache.org/jira/browse/WICKET-5290

Have fun
Sven


On 07.07.2016 14:13, Wayne W wrote:

Hi Sven,

of course: Ok so this is simplified somewhat: lets say we have 4 main tab
areas of the application: Contacts, Files, Calendar, Tasks. When a user
navigates from one area to the next we need to currently do a whole page
refresh, where in fact all we really need to do is refresh a sub panel via
ajax. This already is more 'old school' as I put it in the fact the user
experiences the whole page refreshing rather than say a loading/spinner in
the main panel. We want to make the web pp fell more 'app like' rather than
a succession of web pages. Another example is say we are in the "File" tab
and we want to drill down through some folders, at the moment we need to
refresh the page if we want to support the back button rather than load via
ajax.

It just gives a much less slick experience as the page reloads visually,
and there is more data sent over the wire - slower page loads. But
ultimately it about the users impression of the app and feeling like an app
rather than a bunch of pages.


On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier  wrote:


Hi,

it would be interesting to hear what limitations you're fighting against.
As a server-side rendered framework Wicket surely isn't the new kid on the
block, but I can't think of anything forcing your application to be 'old
school'.

Can you be more specific?

Sven



Am 7. Juli 2016, 13:23, um 13:23, Wayne W 
schrieb:

Hi,

we're been using wicket for some time now and we have a very
established
application used by many clients. It is however feeling some what
dated,
due to the fact the we have to constantly reload pages to access
different
functionality/areas if the app. We use ajax fairly heavily within each
functional area.

The problem is we are starting to 'feel' old school and we're loosing
out
to the competition that are based on the lasted SPA type JS frameworks
talking to APIs. They just feel more slick and more responsive.

Doing some research it seems thats it not possible to transform our
current
wicket app into this form, mainly due to the issues around wicket ajax
state storage and history URL support in older browsers.

Is this something the Wicket is never going to to attempt to support? I
cannot find anything around this subject.

Having a huge investment in our Wicket based application, its going to
be
very very painful to move away from which we must do if we cannot keep
up
with the competition due to framework limitations.

many thanks



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

Re: on upgrade from 7.2 to 7.3 Cannot modify component hierarchy after render phase has started

[Sven Meier]

Hi,

there have been some changes related to queued components recently.
Previously MarkupContainer#onInitialize() would trigger loading of the 
markup, this is no longer the case. See the 7.2 stacktrace:


HomePage.getMarkupResourceStream(MarkupContainer, Class) line: 28
MarkupFactory.getMarkupResourceStream(MarkupContainer, Class) 
line: 320

MarkupCache.getMarkup(MarkupContainer, Class, boolean) line: 296
MarkupFactory.getMarkup(MarkupContainer, Class, boolean) line: 236
MarkupFactory.getMarkup(MarkupContainer, boolean) line: 194
HomePage(MarkupContainer).getAssociatedMarkup() line: 456
HomePage(MarkupContainer).getRegionMarkup() line: 2224
HomePage(MarkupContainer).newDequeueContext() line: 2211
HomePage(MarkupContainer).dequeueAutoComponents() line: 1670 < 
no longer called in 7.3

HomePage(MarkupContainer).onInitialize() line: 1664
HomePage(Page).onInitialize() line: 299

IMHO your best option is to trigger loading of markup by yourself from 
#onInitialize().


Have fun
Sven


On 07.07.2016 12:15, Renner, Ingo wrote:


Hi,

the page classes  of our wicket application read their html markup 
from the filesystem, where they are generated by a CMS system.


In the markup of these pages we have special tags which we replace 
with real tags and add some wicket components to the page.


This is nearly the same way which was/is used in the wicket brix cms.

Last cause: Cannot modify component hierarchy after render phase has 
started (page version cant change then anymore)
WicketMessage: Markup of type 'html' for component 'com.lr.HomePage' 
not found. Enable debug messages for org.apache.wicket.util.resource 
to get a list of all filenames tried:

[Page class = com.lr.HomePage, id = 0, render count = 1]

This is just a demo which shows the same technology used in our real 
code, but in a more simple way:


This is the interesting method from the Page class with some comments:

@Override

*public*IResourceStream getMarkupResourceStream(MarkupContainer 
container, Class containerClass) {


// This simulates loading the template from external source

InputStream src= HomePage.*class*.getResourceAsStream("HomePageSrc.html");

String srcStr= "";

*try*{

srcStr= Streams./readString/(src);

// now replacing my special _markup_ "tag" with a real _html_ tag

srcStr= srcStr.replace("${tile}", "");

// and adding the component to the page

HomePage.*this*.add(*new*Label("tile", Model./of/("Content of dynamic 
component aka tile.")));


} *catch*(IOException e) {

// *TODO*Auto-generated catch block

e.printStackTrace();

}

StringResourceStream stringResourceStream= 
*new*StringResourceStream(srcStr, "text/html");


*return*stringResourceStream;

}

A quickstart is attached. Just switch the version number in the 
pom.xml: It works with 7.2 and breaks with 7.3.


My question now. Is this kind of technology wrong with 7.3 (or was it 
always a bad idea) and how should it be done now, or is 7.3 overreacting?


Mit freundlichen Grüßen / Kind regards

Ingo Renner



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

Re: Style Sheet in page head

[Francois Meillet]

If you look at what is sent by Wicket   (open the Wicket Ajax Debug panel or 
use a debugging proxy like Charles Proxy),
you will see 












The id and type with null value are just extrapolated and added by tools 
(firebugs and so on), but are not in the html page.

François



> Le 7 juil. 2016 à 13:12, Peter Henderson  a 
> écrit :
> 
> Thanks François
> 
> 
> 
> On Thu, Jul 7, 2016 at 11:51 AM, Francois Meillet <
> francois.meil...@gmail.com > wrote:
> 
>> You don't define id and type so there are null.
>> 
>> just add id="yourid" type="text/css"
>> 
>> 
>>  
>> 
>> 
>> 
> Although MDN shows examples without an id or type [1].
> The examples shown by the  html5 standards [2] page also don't have type
> and id for style sheets.
> 
> 
> 
> [1]https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#Examples 
> 
> [2]https://www.w3.org/TR/html5/document-metadata.html#the-link-element 
> 
> 
> 
> 
> 
>> François
>> 
>> 
>> 
>>> Le 7 juil. 2016 à 12:24, Peter Henderson 
>> a écrit :
>>> 
>>> Hello,
>>> 
>>> 
>>> I might have found a small bug.
>>> 
>>> I have a control which has a style sheet link in its head section.
>>> This control is used within a ListView but is initially hidden.
>>> An ajax action causes the control to become visible.
>>> 
>>> The style sheet link added to the page head looks malformed.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Full page reload corrects the header link.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am I doing something wrong or is this a bug?
>>> 
>>> 
>>> I've created a quick start which is available
>>> https://github.com/bollinger/wicket-style-bug
>>> 
>>> 
>>> Thanks
>>> 
>>> --
>>> Peter Henderson
>>> 
>>> Director
>>> Starjar Ltd.
>>> www.starjar.com
>>> 0330 088 1662
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org 
>> 
>> For additional commands, e-mail: users-h...@wicket.apache.org 
>> 
>> 
>> 
> 
> 
> -- 
> Peter Henderson
> 
> Director
> Starjar Ltd.
> www.starjar.com 
> 0330 088 1662

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi Sven,

of course: Ok so this is simplified somewhat: lets say we have 4 main tab
areas of the application: Contacts, Files, Calendar, Tasks. When a user
navigates from one area to the next we need to currently do a whole page
refresh, where in fact all we really need to do is refresh a sub panel via
ajax. This already is more 'old school' as I put it in the fact the user
experiences the whole page refreshing rather than say a loading/spinner in
the main panel. We want to make the web pp fell more 'app like' rather than
a succession of web pages. Another example is say we are in the "File" tab
and we want to drill down through some folders, at the moment we need to
refresh the page if we want to support the back button rather than load via
ajax.

It just gives a much less slick experience as the page reloads visually,
and there is more data sent over the wire - slower page loads. But
ultimately it about the users impression of the app and feeling like an app
rather than a bunch of pages.


On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier  wrote:

> Hi,
>
> it would be interesting to hear what limitations you're fighting against.
> As a server-side rendered framework Wicket surely isn't the new kid on the
> block, but I can't think of anything forcing your application to be 'old
> school'.
>
> Can you be more specific?
>
> Sven
>
>
>
> Am 7. Juli 2016, 13:23, um 13:23, Wayne W 
> schrieb:
> >Hi,
> >
> >we're been using wicket for some time now and we have a very
> >established
> >application used by many clients. It is however feeling some what
> >dated,
> >due to the fact the we have to constantly reload pages to access
> >different
> >functionality/areas if the app. We use ajax fairly heavily within each
> >functional area.
> >
> >The problem is we are starting to 'feel' old school and we're loosing
> >out
> >to the competition that are based on the lasted SPA type JS frameworks
> >talking to APIs. They just feel more slick and more responsive.
> >
> >Doing some research it seems thats it not possible to transform our
> >current
> >wicket app into this form, mainly due to the issues around wicket ajax
> >state storage and history URL support in older browsers.
> >
> >Is this something the Wicket is never going to to attempt to support? I
> >cannot find anything around this subject.
> >
> >Having a huge investment in our Wicket based application, its going to
> >be
> >very very painful to move away from which we must do if we cannot keep
> >up
> >with the competition due to framework limitations.
> >
> >many thanks
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Sven Meier]

Hi,

it would be interesting to hear what limitations you're fighting against.
As a server-side rendered framework Wicket surely isn't the new kid on the 
block, but I can't think of anything forcing your application to be 'old 
school'.

Can you be more specific?

Sven



Am 7. Juli 2016, 13:23, um 13:23, Wayne W  schrieb:
>Hi,
>
>we're been using wicket for some time now and we have a very
>established
>application used by many clients. It is however feeling some what
>dated,
>due to the fact the we have to constantly reload pages to access
>different
>functionality/areas if the app. We use ajax fairly heavily within each
>functional area.
>
>The problem is we are starting to 'feel' old school and we're loosing
>out
>to the competition that are based on the lasted SPA type JS frameworks
>talking to APIs. They just feel more slick and more responsive.
>
>Doing some research it seems thats it not possible to transform our
>current
>wicket app into this form, mainly due to the issues around wicket ajax
>state storage and history URL support in older browsers.
>
>Is this something the Wicket is never going to to attempt to support? I
>cannot find anything around this subject.
>
>Having a huge investment in our Wicket based application, its going to
>be
>very very painful to move away from which we must do if we cannot keep
>up
>with the competition due to framework limitations.
>
>many thanks

Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi,

we're been using wicket for some time now and we have a very established
application used by many clients. It is however feeling some what dated,
due to the fact the we have to constantly reload pages to access different
functionality/areas if the app. We use ajax fairly heavily within each
functional area.

The problem is we are starting to 'feel' old school and we're loosing out
to the competition that are based on the lasted SPA type JS frameworks
talking to APIs. They just feel more slick and more responsive.

Doing some research it seems thats it not possible to transform our current
wicket app into this form, mainly due to the issues around wicket ajax
state storage and history URL support in older browsers.

Is this something the Wicket is never going to to attempt to support? I
cannot find anything around this subject.

Having a huge investment in our Wicket based application, its going to be
very very painful to move away from which we must do if we cannot keep up
with the competition due to framework limitations.

many thanks

Re: Style Sheet in page head

[Peter Henderson]

Thanks François



On Thu, Jul 7, 2016 at 11:51 AM, Francois Meillet <
francois.meil...@gmail.com> wrote:

> You don't define id and type so there are null.
>
> just add id="yourid" type="text/css"
>
> 
>   
> 
>
>
Although MDN shows examples without an id or type [1].
The examples shown by the  html5 standards [2] page also don't have type
and id for style sheets.



[1]https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#Examples
[2]https://www.w3.org/TR/html5/document-metadata.html#the-link-element




> François
>
>
>
> > Le 7 juil. 2016 à 12:24, Peter Henderson 
> a écrit :
> >
> > Hello,
> >
> >
> > I might have found a small bug.
> >
> > I have a control which has a style sheet link in its head section.
> > This control is used within a ListView but is initially hidden.
> > An ajax action causes the control to become visible.
> >
> > The style sheet link added to the page head looks malformed.
> >
> > 
> >  
> > 
> >
> > Full page reload corrects the header link.
> >
> > 
> >  
> > 
> >
> > Am I doing something wrong or is this a bug?
> >
> >
> > I've created a quick start which is available
> > https://github.com/bollinger/wicket-style-bug
> >
> >
> > Thanks
> >
> > --
> > Peter Henderson
> >
> > Director
> > Starjar Ltd.
> > www.starjar.com
> > 0330 088 1662
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Peter Henderson

Director
Starjar Ltd.
www.starjar.com
0330 088 1662

Re: Style Sheet in page head

[Francois Meillet]

You don't define id and type so there are null.

just add id="yourid" type="text/css"


  


François



> Le 7 juil. 2016 à 12:24, Peter Henderson  a 
> écrit :
> 
> Hello,
> 
> 
> I might have found a small bug.
> 
> I have a control which has a style sheet link in its head section.
> This control is used within a ListView but is initially hidden.
> An ajax action causes the control to become visible.
> 
> The style sheet link added to the page head looks malformed.
> 
> 
>  
> 
> 
> Full page reload corrects the header link.
> 
> 
>  
> 
> 
> Am I doing something wrong or is this a bug?
> 
> 
> I've created a quick start which is available
> https://github.com/bollinger/wicket-style-bug
> 
> 
> Thanks
> 
> -- 
> Peter Henderson
> 
> Director
> Starjar Ltd.
> www.starjar.com
> 0330 088 1662


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

Style Sheet in page head

[Peter Henderson]

Hello,


I might have found a small bug.

I have a control which has a style sheet link in its head section.
This control is used within a ListView but is initially hidden.
An ajax action causes the control to become visible.

The style sheet link added to the page head looks malformed.


  


Full page reload corrects the header link.


  


Am I doing something wrong or is this a bug?


I've created a quick start which is available
https://github.com/bollinger/wicket-style-bug


Thanks

-- 
Peter Henderson

Director
Starjar Ltd.
www.starjar.com
0330 088 1662