Re: ajax events and manipulating DOM
Ok, to answer my own question, it was a jquery/javascript issue. Instead
of removing dom, the approach that works is to use appendTo instead:
$('.actionbuttons').appendTo('.btns');
Jason
On 11/14/14, 6:13 PM, Jason Novotny wrote:
Hi,
I'm using jquery datatables which allows customization of table header
by creating html in javascript via "dom" attribute which creates a div :
$('#datatable').dataTable({
"dom": '<"top"<"dropholder"><"postpone"><"btns"><"holder"ip>>t',
"language": {
"info": "_START_-_END_ of _TOTAL_",
"search": ""
},
"aaSorting": [],
"aoColumnDefs": [
{'bSortable': false, 'aTargets': [ 0, 4, 7 ] }
],
'iDisplayLength': 12
});
$('.btns').html('Send');
However I need these buttons to be server-side actions.
My naive solution was to create additional wicket links on the page:
Cancel
Send
and then at the top of my page:
$(function() {
updateDataTable();
});
where I have
function updateDataTable() {
$('#datatable').dataTable({
"dom": '<"top"<"dropholder"><"postpone"><"btns"><"holder"ip>>t',
"language": {
"info": "_START_-_END_ of _TOTAL_",
"search": ""
},
"aaSorting": [],
"aoColumnDefs": [
{'bSortable': false, 'aTargets': [ 0, 4, 7 ] }
],
'iDisplayLength': 12
});
var html = $('.actionbuttons').html();
$('.btns').html(html);
$('.actionbuttons').remove();
}
}
However, the send button when clicked needs to refresh the panel with
an updated data table. So I have:
add(newAjaxSubmitLink("send") {
@Override
protected voidonSubmit(AjaxRequestTarget target, Form form) {
container.addOrReplace(createDataTable());
target.add(container);
target.appendJavaScript("updateDataTable()");
}
});
Now this works the first time when the page loads. It removes the DOM
section with wicket-ized links to the DOM section of the datatable.
Clicking "send" results in an updated table. However, when I click
"send" again, although the display looks good and it has replaced the
DOM, the links seem to have no events associated and it doesn't do
anything. I wonder if a disconnect is going on with the wicket event
registration...
Is there a better way to do this, or am I missing something?
Thanks, Jason
ajax events and manipulating DOM
Hi,
I'm using jquery datatables which allows customization of table header
by creating html in javascript via "dom" attribute which creates a div :
$('#datatable').dataTable({
"dom": '<"top"<"dropholder"><"postpone"><"btns"><"holder"ip>>t',
"language": {
"info": "_START_-_END_ of _TOTAL_",
"search": ""
},
"aaSorting": [],
"aoColumnDefs": [
{'bSortable': false, 'aTargets': [ 0, 4, 7 ] }
],
'iDisplayLength': 12
});
$('.btns').html('Send');
However I need these buttons to be server-side actions.
My naive solution was to create additional wicket links on the page:
Cancel
Send
and then at the top of my page:
$(function() {
updateDataTable();
});
where I have
function updateDataTable() {
$('#datatable').dataTable({
"dom": '<"top"<"dropholder"><"postpone"><"btns"><"holder"ip>>t',
"language": {
"info": "_START_-_END_ of _TOTAL_",
"search": ""
},
"aaSorting": [],
"aoColumnDefs": [
{'bSortable': false, 'aTargets': [ 0, 4, 7 ] }
],
'iDisplayLength': 12
});
var html = $('.actionbuttons').html();
$('.btns').html(html);
$('.actionbuttons').remove();
}
}
However, the send button when clicked needs to refresh the panel with an
updated data table. So I have:
add(newAjaxSubmitLink("send") {
@Override
protected voidonSubmit(AjaxRequestTarget target, Form form) {
container.addOrReplace(createDataTable());
target.add(container);
target.appendJavaScript("updateDataTable()");
}
});
Now this works the first time when the page loads. It removes the DOM
section with wicket-ized links to the DOM section of the datatable.
Clicking "send" results in an updated table. However, when I click
"send" again, although the display looks good and it has replaced the
DOM, the links seem to have no events associated and it doesn't do
anything. I wonder if a disconnect is going on with the wicket event
registration...
Is there a better way to do this, or am I missing something?
Thanks, Jason
RE: Wicke website makeover time?
Sorry, for the confusion - I realize now that I was referring to Chris J Lee's fork of Martijn's work. I cloned Chris J Lee's fork and ran Jekyll on it and looks very modern and sexy indeed. -Original Message- From: Chris Colman [mailto:chr...@stepaheadsoftware.com] Sent: Saturday, 15 November 2014 8:02 AM To: users@wicket.apache.org Subject: RE: Wicke website makeover time? Wow! Martijn has already done what I was suggesting we already do - except I was proposing Bootstrap but Martijn's work looks excellent with whatever CSS it's using. I didn't realize that there was such an active JIRA already covering this. So this worries me - why isn't Martijn's work live yet? If myself or others do work on it or any other new website content/styling will it also be left flapping in the wind? Most people would only want to contribute to a website makeover that has a high chance of being used. What is stopping Martijn's site being updated with the latest content updates from the latest directory in SVN and then released to the wild and what could we do to make that happen? There is some feedback in the JIRA but if the reason it hasn't gone live is that "It's not quite perfect yet" then we have a classic "perfectionist's dilemma" - not an uncommon disease amongst programmers ;) Really guys, Martijn's site looks a million bazillion times better than the current live site - with or without whatever issues people think it might have. I really think we should bite the bullet and do whatever minimal work is required to get Martijn's makeover to 'go live' and then work on other "none showstopper" issues over time after that. What if we agreed on an absolute bare minimum list of show stopper issues that absolutely MUST be resolved in order to take Martijn's work live and then we can distribute the work and "get it done!"? JIRA is probably the best place to compile this list and track progress (as separately assignable subtasks?) but here's one or two: The only major one I can think of is Apache's requirement that site source be in their SVN repo but Martijn's work is on github. I can think of two options for this (could be others): 1. Establish a Git<->SVN bridge somewhere?? So that we can make contributions via our own Git clones from which an admin can cherrypick pull requests and then shoot these changes over the bridge to Apache's SVN repo. 2. Do a once off port to SVN and then use SVN from then on with perhaps SVN branching (obviously not as elegant as git branching) I do agree with comment in the emails that there is quite a lot of content on that single home page. I don't think this is a showstopper that needs to be fixed before 'go live' but rather something we could work on afterwards. I think we could create a few new Jekyll layouts: one for a landing page (home page) and others where distinctive page types are required - maybe the quickstart? Thoughts? Regards, Chris -Original Message- From: Andrea Del Bene [mailto:an.delb...@gmail.com] Sent: Saturday, 15 November 2014 6:06 AM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? One last useful reference is https://issues.apache.org/jira/browse/WICKET-3341. This is the "official" issue to discuss new site design. Personally I like very much https://issues.apache.org/jira/secure/attachment/12583195/wicket-flat-ne w-top.002.png which is a variation of the flat theme. > I think we haven't mentioned yet the nice work done by Chris J. Lee: > > https://github.com/chrisjlee/wicket-site > > This should be the last version of Martijn's initial work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicke website makeover time?
Wow! Martijn has already done what I was suggesting we already do - except I was proposing Bootstrap but Martijn's work looks excellent with whatever CSS it's using. I didn't realize that there was such an active JIRA already covering this. So this worries me - why isn't Martijn's work live yet? If myself or others do work on it or any other new website content/styling will it also be left flapping in the wind? Most people would only want to contribute to a website makeover that has a high chance of being used. What is stopping Martijn's site being updated with the latest content updates from the latest directory in SVN and then released to the wild and what could we do to make that happen? There is some feedback in the JIRA but if the reason it hasn't gone live is that "It's not quite perfect yet" then we have a classic "perfectionist's dilemma" - not an uncommon disease amongst programmers ;) Really guys, Martijn's site looks a million bazillion times better than the current live site - with or without whatever issues people think it might have. I really think we should bite the bullet and do whatever minimal work is required to get Martijn's makeover to 'go live' and then work on other "none showstopper" issues over time after that. What if we agreed on an absolute bare minimum list of show stopper issues that absolutely MUST be resolved in order to take Martijn's work live and then we can distribute the work and "get it done!"? JIRA is probably the best place to compile this list and track progress (as separately assignable subtasks?) but here's one or two: The only major one I can think of is Apache's requirement that site source be in their SVN repo but Martijn's work is on github. I can think of two options for this (could be others): 1. Establish a Git<->SVN bridge somewhere?? So that we can make contributions via our own Git clones from which an admin can cherrypick pull requests and then shoot these changes over the bridge to Apache's SVN repo. 2. Do a once off port to SVN and then use SVN from then on with perhaps SVN branching (obviously not as elegant as git branching) I do agree with comment in the emails that there is quite a lot of content on that single home page. I don't think this is a showstopper that needs to be fixed before 'go live' but rather something we could work on afterwards. I think we could create a few new Jekyll layouts: one for a landing page (home page) and others where distinctive page types are required - maybe the quickstart? Thoughts? Regards, Chris -Original Message- From: Andrea Del Bene [mailto:an.delb...@gmail.com] Sent: Saturday, 15 November 2014 6:06 AM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? One last useful reference is https://issues.apache.org/jira/browse/WICKET-3341. This is the "official" issue to discuss new site design. Personally I like very much https://issues.apache.org/jira/secure/attachment/12583195/wicket-flat-ne w-top.002.png which is a variation of the flat theme. > I think we haven't mentioned yet the nice work done by Chris J. Lee: > > https://github.com/chrisjlee/wicket-site > > This should be the last version of Martijn's initial work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket jQuery js loaded twice when modal window opened
Yes, the anticache parameter was being added by jQuery as I was trying to get the content for new page in modal window using jQuery ajax get. I will load the new page in modal window using iframe to avoid the javascript of new page affecting the page in parent window, to resolve the issue. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-jQuery-js-loaded-twice-when-modal-window-opened-tp4668156p4668417.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicke website makeover time?
One last useful reference is https://issues.apache.org/jira/browse/WICKET-3341. This is the "official" issue to discuss new site design. Personally I like very much https://issues.apache.org/jira/secure/attachment/12583195/wicket-flat-new-top.002.png which is a variation of the flat theme. I think we haven't mentioned yet the nice work done by Chris J. Lee: https://github.com/chrisjlee/wicket-site This should be the last version of Martijn's initial work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RadioGroup not updating in ajax event
We have an ajax event initiated by one panel that affects the data, and needs
to force a redraw of a radiogroup in another panel. The ajax event arrives,
we add the radiogroup to the target, update the model that backs the
ListView, but the populateItem method never re-fires to redraw. Note that
this is in Wicket 1.4.7.
The following is the creation of the radio group.
group = new RadioGroup("roles", new Model(getDefaultBean()));
group.setOutputMarkupId(true);
group.setRenderBodyOnly(false);
add(group);
appBean.setUmcOnlyRoles(umcOnlyRoles);
LoadableDetachableModel modelRoles = new LoadableDetachableModel() {
protected Object load() {
return appBean.getUmcOnlyRoles();
}
};
// add all roles
ListView rolesList = new ListView("radioList",
modelRoles){
protected void populateItem(final ListItem item) {
final KeyValueBean bean = item.getModelObject();
@SuppressWarnings("rawtypes")
Radio radio = new Radio("radio", item.getModel()) {
//snipped for brevity
}
}
};
rolesList.setOutputMarkupId(true);
rolesList.setReuseItems(true);
group.add(rolesList);
In the ajax event we do this:
Panel app = (Panel)get("apps");
UMCApplicationPanel umc = (UMCApplicationPanel)app.get("umcPanel");
RadioGroup rolesMarkup = (RadioGroup)umc.get("roles");
//snipper for brevity
bean.setUmcOnlyRoles(umcOnlyRoles);
bean.seteShareChecked(eShareChecked);
target.addComponent(rolesMarkup);
The "bean" in this event is the same object as the "appBean" in the load
method of the detachable model in the constructor above. I can confirm that
the detachable model load fires and the right data is in it. Yet the
populateItem never runs...so the list is unchanged.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/RadioGroup-not-updating-in-ajax-event-tp4668415.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Problems with wicket serialization
Hi, I have an application using Wicket 1.5.10 and I'm having problems with the serialization of FileUpload component. The problem is that the FileUpload creates a temporary file in the temp directory and when the wicket deserializes the page, if file (*temp directory*) no exists the following exception occurs: https://gist.github.com/anonymous/c33ee20df9c68b118459 This problem only occurs when multiple browser tabs are open. Suggestions of how to solve? best, Laécio.
Re: Wicke website makeover time?
I think we haven't mentioned yet the nice work done by Chris J. Lee: https://github.com/chrisjlee/wicket-site This should be the last version of Martijn's initial work. Hi Martijn, Did you build that page via jekyll or from raw HTML? I'm thinking we could easily restructure the current jekyll content to output in that layout/style. I'm playing around with a new type of layout called 'landing' (for landing page - eg., like the home page) where things are laid out like your sample. Regards, Chris -Original Message- From: Guillaume Smet [mailto:guillaume.s...@gmail.com] Sent: Friday, 14 November 2014 11:50 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? Hi, Personnally, I really liked what Martijn did here: http://people.apache.org/~dashorst/wicket-flat/ It's clean and has personnality. The only thing IMHO is that a one page design for this amount of information is perhaps a bit too much. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicke website makeover time?
Hi Martijn, Did you build that page via jekyll or from raw HTML? I'm thinking we could easily restructure the current jekyll content to output in that layout/style. I'm playing around with a new type of layout called 'landing' (for landing page - eg., like the home page) where things are laid out like your sample. Regards, Chris -Original Message- From: Guillaume Smet [mailto:guillaume.s...@gmail.com] Sent: Friday, 14 November 2014 11:50 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? Hi, Personnally, I really liked what Martijn did here: http://people.apache.org/~dashorst/wicket-flat/ It's clean and has personnality. The only thing IMHO is that a one page design for this amount of information is perhaps a bit too much. -- Guillaume On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman wrote: >>> I think a multi phase approach might have more chance of success - as > I >>> said in my immediate previous post if we could live with jekyll > source >>> for phase one (even though it may not be ideal) then we can keep most > of >>> the current content source 'as is' and simply choose a decent modern >>> Bootstrap CSS template to re-render it in to deliver the best 'bang > for >>> buck' possible at this early stage. >> >>Bootstrap would be too standard and anonymous and would ultimately be >>a ball and chain. A little .less and responsiveness can easily be >>achieved without going bootstrap. > > IMHO standard and anonymous looks a lot better than retro late 1990s ;) > > Having said that, there are plenty of Bootstrap customization tools > (Bootswatch etc.,) that would allow us to customize very quickly and so > move well away from the standard and anonymous Bootstrap look and feel - > I would never use the standard Bootstrap template without customization > - it's too generic these days. > > While we could go "home grown" i.e. without the help of Bootstrap and do > a little .less (or .sass) and responsiveness the use of Bootstrap's > already awesome (tried and tested and working) responsiveness and it's > cross browser compatibility (who wants to deal with issues like that in > 2014?) could make this a very quick project. > > I know I don't have a lot of time to spare to make greenfield, home > grown responsiveness that works across IE7+, FF, Chrome and Safari. > > So a quick project is a good project for me. If it ends up looking a lot > more modern and sexy than the current site and it takes hours instead of > weeks then I think it's going to happen. If we insist on not using a > grid/CSS/JS template like Bootstrap and so make the effort measured in > weeks instead of hours then I fear that the website will still have it's > current look and feel in a years time. > > I don't think we'll be locked into Bootstrap anyway. If the translator > uses bootstrap then the copy can remain Bootstrap free and easily moved > to another CSS/JS library later if required. > >> >>> Or does Jekyll have a fairly fixed translator that provides little >>> customizability? >> >>Jekyll is fully customizable. It's just a translator from markdown to >>HTML with templates and includes. >> >>Martijn >> >>- >>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicke website makeover time?
Yes, that looks very nice indeed. That's the sort of website I'd love my clients to see when I tell them I'm planning to build their 'next big thing' using Wicket. -Original Message- From: Guillaume Smet [mailto:guillaume.s...@gmail.com] Sent: Friday, 14 November 2014 11:50 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? Hi, Personnally, I really liked what Martijn did here: http://people.apache.org/~dashorst/wicket-flat/ It's clean and has personnality. The only thing IMHO is that a one page design for this amount of information is perhaps a bit too much. -- Guillaume On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman wrote: >>> I think a multi phase approach might have more chance of success - as > I >>> said in my immediate previous post if we could live with jekyll > source >>> for phase one (even though it may not be ideal) then we can keep most > of >>> the current content source 'as is' and simply choose a decent modern >>> Bootstrap CSS template to re-render it in to deliver the best 'bang > for >>> buck' possible at this early stage. >> >>Bootstrap would be too standard and anonymous and would ultimately be >>a ball and chain. A little .less and responsiveness can easily be >>achieved without going bootstrap. > > IMHO standard and anonymous looks a lot better than retro late 1990s ;) > > Having said that, there are plenty of Bootstrap customization tools > (Bootswatch etc.,) that would allow us to customize very quickly and so > move well away from the standard and anonymous Bootstrap look and feel - > I would never use the standard Bootstrap template without customization > - it's too generic these days. > > While we could go "home grown" i.e. without the help of Bootstrap and do > a little .less (or .sass) and responsiveness the use of Bootstrap's > already awesome (tried and tested and working) responsiveness and it's > cross browser compatibility (who wants to deal with issues like that in > 2014?) could make this a very quick project. > > I know I don't have a lot of time to spare to make greenfield, home > grown responsiveness that works across IE7+, FF, Chrome and Safari. > > So a quick project is a good project for me. If it ends up looking a lot > more modern and sexy than the current site and it takes hours instead of > weeks then I think it's going to happen. If we insist on not using a > grid/CSS/JS template like Bootstrap and so make the effort measured in > weeks instead of hours then I fear that the website will still have it's > current look and feel in a years time. > > I don't think we'll be locked into Bootstrap anyway. If the translator > uses bootstrap then the copy can remain Bootstrap free and easily moved > to another CSS/JS library later if required. > >> >>> Or does Jekyll have a fairly fixed translator that provides little >>> customizability? >> >>Jekyll is fully customizable. It's just a translator from markdown to >>HTML with templates and includes. >> >>Martijn >> >>- >>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicke website makeover time?
Hi, Personnally, I really liked what Martijn did here: http://people.apache.org/~dashorst/wicket-flat/ It's clean and has personnality. The only thing IMHO is that a one page design for this amount of information is perhaps a bit too much. -- Guillaume On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman wrote: >>> I think a multi phase approach might have more chance of success - as > I >>> said in my immediate previous post if we could live with jekyll > source >>> for phase one (even though it may not be ideal) then we can keep most > of >>> the current content source 'as is' and simply choose a decent modern >>> Bootstrap CSS template to re-render it in to deliver the best 'bang > for >>> buck' possible at this early stage. >> >>Bootstrap would be too standard and anonymous and would ultimately be >>a ball and chain. A little .less and responsiveness can easily be >>achieved without going bootstrap. > > IMHO standard and anonymous looks a lot better than retro late 1990s ;) > > Having said that, there are plenty of Bootstrap customization tools > (Bootswatch etc.,) that would allow us to customize very quickly and so > move well away from the standard and anonymous Bootstrap look and feel - > I would never use the standard Bootstrap template without customization > - it's too generic these days. > > While we could go "home grown" i.e. without the help of Bootstrap and do > a little .less (or .sass) and responsiveness the use of Bootstrap's > already awesome (tried and tested and working) responsiveness and it's > cross browser compatibility (who wants to deal with issues like that in > 2014?) could make this a very quick project. > > I know I don't have a lot of time to spare to make greenfield, home > grown responsiveness that works across IE7+, FF, Chrome and Safari. > > So a quick project is a good project for me. If it ends up looking a lot > more modern and sexy than the current site and it takes hours instead of > weeks then I think it's going to happen. If we insist on not using a > grid/CSS/JS template like Bootstrap and so make the effort measured in > weeks instead of hours then I fear that the website will still have it's > current look and feel in a years time. > > I don't think we'll be locked into Bootstrap anyway. If the translator > uses bootstrap then the copy can remain Bootstrap free and easily moved > to another CSS/JS library later if required. > >> >>> Or does Jekyll have a fairly fixed translator that provides little >>> customizability? >> >>Jekyll is fully customizable. It's just a translator from markdown to >>HTML with templates and includes. >> >>Martijn >> >>- >>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicke website makeover time?
>> I think a multi phase approach might have more chance of success - as I >> said in my immediate previous post if we could live with jekyll source >> for phase one (even though it may not be ideal) then we can keep most of >> the current content source 'as is' and simply choose a decent modern >> Bootstrap CSS template to re-render it in to deliver the best 'bang for >> buck' possible at this early stage. > >Bootstrap would be too standard and anonymous and would ultimately be >a ball and chain. A little .less and responsiveness can easily be >achieved without going bootstrap. IMHO standard and anonymous looks a lot better than retro late 1990s ;) Having said that, there are plenty of Bootstrap customization tools (Bootswatch etc.,) that would allow us to customize very quickly and so move well away from the standard and anonymous Bootstrap look and feel - I would never use the standard Bootstrap template without customization - it's too generic these days. While we could go "home grown" i.e. without the help of Bootstrap and do a little .less (or .sass) and responsiveness the use of Bootstrap's already awesome (tried and tested and working) responsiveness and it's cross browser compatibility (who wants to deal with issues like that in 2014?) could make this a very quick project. I know I don't have a lot of time to spare to make greenfield, home grown responsiveness that works across IE7+, FF, Chrome and Safari. So a quick project is a good project for me. If it ends up looking a lot more modern and sexy than the current site and it takes hours instead of weeks then I think it's going to happen. If we insist on not using a grid/CSS/JS template like Bootstrap and so make the effort measured in weeks instead of hours then I fear that the website will still have it's current look and feel in a years time. I don't think we'll be locked into Bootstrap anyway. If the translator uses bootstrap then the copy can remain Bootstrap free and easily moved to another CSS/JS library later if required. > >> Or does Jekyll have a fairly fixed translator that provides little >> customizability? > >Jekyll is fully customizable. It's just a translator from markdown to >HTML with templates and includes. > >Martijn > >- >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RenderStrategy.ONE_PASS_RENDER possible for single page?
Ah yes, brilliant - didn't think of that. Thanks Martin - that works a treat. On Fri, Nov 14, 2014 at 11:00 AM, Martin Grigorov wrote: > You can setup your own PageRenderer > via org.apache.wicket.Application#setPageRendererProvider. > It should return the correct redirect policy per page type. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Fri, Nov 14, 2014 at 12:57 PM, Wayne W > wrote: > > > Hi, > > > > it looks like we cannot make the page stateless as we have many links > that > > require the model etc. > > > > Martin- regarding RedirectPolicy#Never - is there any way we can 'mark' > the > > page to use that? As people are coming to this page from a mount url > (with > > a parameter), so we never get a chance to do something like: > > > > > > scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new > > PageProvider(page), > > > > RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT)); > > > > > > > > > > On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov > > wrote: > > > > > See how RequestCycle#setResponsePage() works. > > > You need to use RedirectPolicy#Never. > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier wrote: > > > > > > > Hi, > > > > > > > > your page doesn't become stateless, just by claiming it to be. > > > > #setStatelessHint() is just a hint. > > > > > > > > Here's a real stateless page: > > > > > > > >http://www.wicket-library.com/wicket-examples/stateless/foo > > > > > > > > Regards > > > > Sven > > > > > > > > > > > > > > > > On 11/13/2014 03:27 PM, Wayne W wrote: > > > > > > > >> Hi Sven, > > > >> > > > >> I tried setting setStatelessHint(true); but it always does a 302 > > > redirect. > > > >> I see something like this in the Net panel in Firebug: > > > >> > > > >> https://www.example.com/share/df43f 302 > > > >> https://www.example.com/share/df43f?1 200 > > > >> > > > >> Any idea? > > > >> thanks > > > >> > > > >> On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier > wrote: > > > >> > > > >> Hi, > > > >>> > > > >>> make your page stateless, then no redirection will occur. > > > >>> > > > >>> Sven > > > >>> > > > >>> > > > >>> On 11/13/2014 11:55 AM, Wayne W wrote: > > > >>> > > > >>> Hi, > > > > > > We have an issue with hyperlinks Microsoft Word and Excel > documents. > > > Its > > > seems to vary from version and OS, but the long and short of it is > > > that > > > Word when a user clicks on a link it uses an internal library to > try > > > and > > > access the page, and once it gets a HTTP 200 it will open the > > default > > > browser. We have a page that is used for sharing files so it gets > > > added > > > to > > > documents. > > > > > > We have several customers complaining they cannot open these > links, > > > and > > > I > > > can verify this seems to happen depending on OS (Mac is worse for > > > example). > > > After doing a lot of digging about the only thing we can do is > make > > > sure > > > we > > > return a HTTP 200 from the first request, as anything else seems > to > > > sometimes work, sometimes not. > > > > > > So to my question: > > > > > > Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single > > page > > > only? We don't really want to loose the advantages of the 302 > > redirect > > > elsewhere > > > > > > Any ideas? > > > > > > many thanks > > > Wayne > > > > > > > > > > > - > > > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > >>> For additional commands, e-mail: users-h...@wicket.apache.org > > > >>> > > > >>> > > > >>> > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > >
Re: RenderStrategy.ONE_PASS_RENDER possible for single page?
You can setup your own PageRenderer via org.apache.wicket.Application#setPageRendererProvider. It should return the correct redirect policy per page type. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Nov 14, 2014 at 12:57 PM, Wayne W wrote: > Hi, > > it looks like we cannot make the page stateless as we have many links that > require the model etc. > > Martin- regarding RedirectPolicy#Never - is there any way we can 'mark' the > page to use that? As people are coming to this page from a mount url (with > a parameter), so we never get a chance to do something like: > > > scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new > PageProvider(page), > > RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT)); > > > > > On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov > wrote: > > > See how RequestCycle#setResponsePage() works. > > You need to use RedirectPolicy#Never. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier wrote: > > > > > Hi, > > > > > > your page doesn't become stateless, just by claiming it to be. > > > #setStatelessHint() is just a hint. > > > > > > Here's a real stateless page: > > > > > >http://www.wicket-library.com/wicket-examples/stateless/foo > > > > > > Regards > > > Sven > > > > > > > > > > > > On 11/13/2014 03:27 PM, Wayne W wrote: > > > > > >> Hi Sven, > > >> > > >> I tried setting setStatelessHint(true); but it always does a 302 > > redirect. > > >> I see something like this in the Net panel in Firebug: > > >> > > >> https://www.example.com/share/df43f 302 > > >> https://www.example.com/share/df43f?1 200 > > >> > > >> Any idea? > > >> thanks > > >> > > >> On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier wrote: > > >> > > >> Hi, > > >>> > > >>> make your page stateless, then no redirection will occur. > > >>> > > >>> Sven > > >>> > > >>> > > >>> On 11/13/2014 11:55 AM, Wayne W wrote: > > >>> > > >>> Hi, > > > > We have an issue with hyperlinks Microsoft Word and Excel documents. > > Its > > seems to vary from version and OS, but the long and short of it is > > that > > Word when a user clicks on a link it uses an internal library to try > > and > > access the page, and once it gets a HTTP 200 it will open the > default > > browser. We have a page that is used for sharing files so it gets > > added > > to > > documents. > > > > We have several customers complaining they cannot open these links, > > and > > I > > can verify this seems to happen depending on OS (Mac is worse for > > example). > > After doing a lot of digging about the only thing we can do is make > > sure > > we > > return a HTTP 200 from the first request, as anything else seems to > > sometimes work, sometimes not. > > > > So to my question: > > > > Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single > page > > only? We don't really want to loose the advantages of the 302 > redirect > > elsewhere > > > > Any ideas? > > > > many thanks > > Wayne > > > > > > > - > > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > >>> For additional commands, e-mail: users-h...@wicket.apache.org > > >>> > > >>> > > >>> > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > >
Re: RenderStrategy.ONE_PASS_RENDER possible for single page?
Hi, it looks like we cannot make the page stateless as we have many links that require the model etc. Martin- regarding RedirectPolicy#Never - is there any way we can 'mark' the page to use that? As people are coming to this page from a mount url (with a parameter), so we never get a chance to do something like: scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new PageProvider(page), RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT)); On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov wrote: > See how RequestCycle#setResponsePage() works. > You need to use RedirectPolicy#Never. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier wrote: > > > Hi, > > > > your page doesn't become stateless, just by claiming it to be. > > #setStatelessHint() is just a hint. > > > > Here's a real stateless page: > > > >http://www.wicket-library.com/wicket-examples/stateless/foo > > > > Regards > > Sven > > > > > > > > On 11/13/2014 03:27 PM, Wayne W wrote: > > > >> Hi Sven, > >> > >> I tried setting setStatelessHint(true); but it always does a 302 > redirect. > >> I see something like this in the Net panel in Firebug: > >> > >> https://www.example.com/share/df43f 302 > >> https://www.example.com/share/df43f?1 200 > >> > >> Any idea? > >> thanks > >> > >> On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier wrote: > >> > >> Hi, > >>> > >>> make your page stateless, then no redirection will occur. > >>> > >>> Sven > >>> > >>> > >>> On 11/13/2014 11:55 AM, Wayne W wrote: > >>> > >>> Hi, > > We have an issue with hyperlinks Microsoft Word and Excel documents. > Its > seems to vary from version and OS, but the long and short of it is > that > Word when a user clicks on a link it uses an internal library to try > and > access the page, and once it gets a HTTP 200 it will open the default > browser. We have a page that is used for sharing files so it gets > added > to > documents. > > We have several customers complaining they cannot open these links, > and > I > can verify this seems to happen depending on OS (Mac is worse for > example). > After doing a lot of digging about the only thing we can do is make > sure > we > return a HTTP 200 from the first request, as anything else seems to > sometimes work, sometimes not. > > So to my question: > > Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page > only? We don't really want to loose the advantages of the 302 redirect > elsewhere > > Any ideas? > > many thanks > Wayne > > > - > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >>> > >>> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: clearing feedback messages on Ajax upload
On Fri, Nov 14, 2014 at 1:47 AM, Garret Wilson
wrote:
> Martin, after fixing the ID selector ("#id7") it works great! (The page
> jumps up because the feedback area disappears, but I can live with that for
> now.) It even
How is your CSS ? ;-)
Instead of $('#id7').empty() you can use $('#id7').css('visibility',
'hidden') or $('#id7').css('opacity', 0) to hide the HTML element but keep
its visual space, so it won't jump.
> works in conjunction with Sven Meier's confirmation message button <
> https://cwiki.apache.org/confluence/x/X4U>.
>
> Very nice. Thank you very much, Martin!
>
> I really recommend that Wicket add some prebuilt behaviors. There should
> be some sort of Ajax "clear component" behavior, and some "Ajax
> confirmation" behavior, etc. This is so that we can get hard-coded, manual
> JavaScript out of our code, and start developing in terms of
> semantically-named prebuilt classes rather than coding JavaScript
> boilerplate. Now I know that the Ajax core team hate this idea, because
> they say, 1) "Wicket is so easy that you can just add in whatever you want;
> we don't need to encapsulate this in a class", and 2) "there are so many
> different ways people want to do it, we don't even want to include one or
> two of them in the Wicket library". I don't want to start that argument
> here; I'll write an essay about it another day.
>
Looking forward to your essay! ;-)
I've shown you three ways to "hide" an HTML element so far. None of them
are good enough for userX because (s)he wants to do that with CSS effects
(fadeOut, easeOut, with rotation, with skew, ...)
I hope you understand we cannot add all this in the library.
It is simple enough so every application developer can write the JS
one-liner to accomplish the task.
Hint:
A clever way would be to set a CSS class to the element you want to hide.
This way the designer (the CSS expert) can do all of the above without
bothering you (the Java developer) every time the requirement changes.
$('#id7').addClass('someClass')
>
> For now I'll just hard-code the JavaScript as Martin suggested and get my
> app working. Thanks again, Martin! Very helpful.
>
> Garret
>
>
> On 11/13/2014 8:39 PM, Martin Grigorov wrote:
>
>> On Fri, Nov 14, 2014 at 12:36 AM, Garret Wilson
>> wrote:
>>
>> I actually mistyped; I greatly prefer option A, not B, below. So Martin,
>>> your suggestion sounds good.
>>>
>>> My JavaScript is great, but my JQuery is not so hot. I added your code
>>> and... my AjaxSubmitLink now no longer performs an upload at all. Here's
>>> the script that's being added to the page:
>>>
>>>
>>> /*>> Wicket.Event.add(window, "domready", function(event) {
>>> new Wicket.WUPB('id4', 'id5', 'id6',
>>> '../resource/org.apache.wicket.Application/org.apache.
>>> wicket.extensions.ajax.markup.html.form.upload.
>>> UploadProgressBar?upload=5',
>>> 'id3', 'Upload starting...');;
>>>
>>>
>> Wicket.Ajax.ajax({"u":"./com.example.ExamplePage?5-4.
>>> IBehaviorListener.0-form-go","m":"POST","c":"id8","f":"id4",
>>> "mp":true,"sc":"go","bsh":[function(attrs,
>>> jqXHR, settings){$('#'id7).empty();}],"e":"click"});;
>>>
>>> it should produce $('#id7').empty(). Note the string parameter to $()
>> I see that my example is broken.
>> Check for JS errors in the Dev tools console when you deal with JS ;-)
>>
>>
>> ;});
>>> /*]]>*/
>>>
>>>
>>>
>>> Here's what my button (id8) HTML looks like:
>>>
>>>
>>>
>>>Go!
>>>
>>>
>>>
>>> id7 is indeed the ID of the feedback (which starts out empty
>>> anyway).
>>>
>>> Garret
>>>
>>> P.S. A few IDs and strings were changed here and there to generalize the
>>> code.
>>>
>>>
>>> On 11/13/2014 7:50 PM, Martin Grigorov wrote:
>>>
>>> Hi,
On Thu, Nov 13, 2014 at 11:36 PM, Garret Wilson <
gar...@globalmentor.com>
wrote:
Hi, all. I've done a bit of searching to find the answer, and nothing
> quite seemed to fit, or was obsolete, or was deprecated, or was vague.
> So
> I'll ask on the list.
>
> I have a page that uses a multipart form submit. It allows the user to
> select a file, and has an AjaxSubmitLink with the label "Go" that 1)
> uploads a large file and then 2) does something that takes a long time.
> When finished, it calls info("finished!") to show a success message in
> the
> feedback area.
>
> So let's suppose that the user selects a file and selects "Go". After
> the
> file is uploaded, the processing takes place and the feedback area says
> "finished!" Perfect.
>
> Question: If the user selects /another/ file and selects "Go" /again/,
> how
> can I immediately remove the "finished!" message, either A) as soon as
> the
> user selects "Go" or B) as soon as the file finishes uploading but
> before
> processeing starts? (I greatly prefer option B.)
>
>
