Re: Invoke Wicket from JavaSctipt
Pay attention to the details: In your pseudo code you have an array of objects with single key/value pair. In my simple code there is an object with many key/value pairs. Martin Grigorov Wicket Training and Consulting On Wed, Jan 29, 2014 at 9:22 PM, Entropy wrote: > Thanks. Using the "advanced" method worked. Though I wasn't repeating > parameters, so I am not sure why the previous didn't work. But it doesn't > matter now. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Invoke-Wicket-from-JavaSctipt-tp4664043p4664050.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: Which is recomended way to implemen an editable repeating view
Take your pick at one of the Repeaters from: http://www.wicket-library.com/wicket-examples/index.html More on them in Ch 13 "Displaying multiple items with repeaters" of the Wicket free guide at: http://wicket.apache.org/guide/guide/repeaters.html Or pruchase a book on Wicket such as Wicket in Action: http://wicket.apache.org/learn/books/ On Wed, Jan 29, 2014 at 5:23 AM, cosmindumy wrote: > Hello, > I want to know which is the best way to implement a repeating view, > preferable data view which contains an input field in each row. > On submit, I need to get an iterator to get reference both to row model > (example a Person object) and to editable component (ex an input text for > age). The input must be processed and model updated. > Thanks in advance. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Which-is-recomended-way-to-implemen-an-editable-repeating-view-tp4664028.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: XSS in wicket. Wicket fault or my fault?
No need, Wicket escapes your model objects, see
Component#setEscapeModelStrings(true) for when HTML should be escaped and
thus the browser won't execute it as HTML or JS.
http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/Component.html#setEscapeModelStrings(boolean)
That is on by default, so you should switch to using a wicket model for
your label.
See the bottom section 11.1 "What is a model?" of the wicket free guide at:
http://wicket.apache.org/guide/guide/modelsforms.html#modelsforms_1
Also, older Wicket in Action:
http://www.javaranch.com/journal/2008/10/using-wicket-labels-and-links.html
On Wed, Jan 29, 2014 at 12:26 PM, Gonzalo Aguilar Delgado <
gagui...@aguilardelgado.com> wrote:
> Hi there,
>
> I'm building an application for a client and my security advisor told me
> about a XSS attack that can be performed on the site.
>
> When user logs-in I welcome they by Saying "Hello user".
>
>
>
> Hello ${realName}.
> Welcome to the Synapse web.
>
>
>
>
> As you can see I use I18N so this is not the real text that will show up,
> but's similar.
>
> I used to think that wicket validated output before building web but the
> white hat hacked it by just putting a fake name into the database. Too easy
> for me...
>
> The content of realName is:
>
> '';!--"alert('XSS')=&{()}
>
>
> So I ended with:
>
> Hello'';!--"alert('XSS')=&{()}
>
> In the web page. And the script executed on login.
>
> I was thinking about baking a method into my DAO classes to validate
> everything that goes to the database. But it should be a better solution.
>
> Can you point me to right one?
>
>
>
> Best regards,
>
>
>
Re: Invoke Wicket from JavaSctipt
Thanks. Using the "advanced" method worked. Though I wasn't repeating parameters, so I am not sure why the previous didn't work. But it doesn't matter now. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Invoke-Wicket-from-JavaSctipt-tp4664043p4664050.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
ApacheCon US 2014 Call for Presentations!
>From my asking on dev@ it seems like there won't be a presence for Wicket at the revamped ApacheCon, which would be a huge shame. I am unable to make it due to scheduling conflicts, otherwise I would've done a whole Wicket track! It would be great if anyone would submit a talk about Wicket-introductory, intermediate or advanced. The organizers have a lot of room for talks so there's a good chance of having a good track for Wicket. As far as I know there is no requirement to be a committer to submit a talk. If you or your boss is unable to pay for travel, the Travel Assistance Committee is there to help. Every time I was at ApacheCon I found it to be a great experience, especially meeting with other projects (Maven, Tomcat, Infrastructure, the Board, Incubator, etc.) The beer was also great and the hackathons were fun too. You'll get the chance to meet folks from all over the world and make new friends. >From the conference organizers: On the off chance that anyone has still missed it ... The Call for Papers for ApacheCon North America 2014 closes on Saturday, February 1. We're looking for talks on any aspect of the Apache Software Foundation - software, community, philosophy, or any other aspect of life at Apache or the surrounding ecosystem. Talks may be submitted at http://events.linuxfoundation. org/events/apachecon-north-america/program/cfp The Linux Foundation, producers of LinuxCon, are producing our conference, but we are responsible for providing and selecting the content. We need you there to represent your project. We have more room for talks than we've had any previous year, so we can have the intro, intermediate and advanced talk where previously we had room only for one. This gives us the opportunity to draw an audience for projects that previously had only one talk, making it very hard to get anyone to pay to attend for that content. So we have an opportunity to showcase projects that have been ignored before. Please don't skip submitting because we haven't had room for you at previous events.
XSS in wicket. Wicket fault or my fault?
Hi there,
I'm building an application for a client and my security advisor told me
about a XSS attack that can be performed on the site.
When user logs-in I welcome they by Saying "Hello user".
Hello ${realName}.
Welcome to the Synapse web.
As you can see I use I18N so this is not the real text that will show
up, but's similar.
I used to think that wicket validated output before building web but the
white hat hacked it by just putting a fake name into the database. Too
easy for me...
The content of realName is:
'';!--"alert('XSS')=&{()}
So I ended with:
Hello'';!--"alert('XSS')=&{()}
In the web page. And the script executed on login.
I was thinking about baking a method into my DAO classes to validate everything
that goes to the database. But it should be a better solution.
Can you point me to right one?
Best regards,
Re: AjaxLazyLoadPanel loading asynchronously
On 29 January 2014 12:28, Vishal Popat wrote: > Hi, > > I have a situation where I have to make multiple REST calls to different > suppliers. > I currently am using AjaxLazyLoadPanel to make these calls but loading > time is very slow and not scaleable if I wanted to add more suppliers. > > Is there a way to make AjaxLazyLoadPanel asynchronously? > I have read some older posts on the forum but not sure if they are the > best way in Wicket 6. > Or is there an alternative approach? > > Many thanks > Vishal > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > You could try native web sockets. Get your worker threads to broadcast a message to the page, it ends up being very similar to an ajax update. -- Peter Henderson
Re: Invoke Wicket from JavaSctipt
Hi,
extra parameters supports two "syntaxes":
- simple:
{
k1: v1,
k2: v2
}
- advanced:
[ {name: "k1", value: "v1"}, {name: "k2", value: "v2"} ]
The advanced way should be used when you have several values for the same
key.
On Wed, Jan 29, 2014 at 4:31 PM, Entropy wrote:
> I want a javascript method to wrap the wicket invocation. I passed the
> following to Wicket.Ajax.ajax. This is what I see in firebug.
>
> attrs {
> c="grid6",
> u="./?3-6.IBehaviorListene...ent-assetListTable-grid",
> ep=[{action="cellClick"},
> {key="8"},
> {column="caseNumber"}
> ]
> }
>
> But on the server, in the behavior I do the following:
>
> final IRequestParameters parms =
> requestCycle.getRequest().getRequestParameters();
> String val = parms.getParameterValue("action").toString();
>
> val is null. So I must not be providing the parameters correctly. What am
> I doing wrong? This seems to match the examples I see.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Invoke-Wicket-from-JavaSctipt-tp4664043.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
>
>
Invoke Wicket from JavaSctipt
I want a javascript method to wrap the wicket invocation. I passed the
following to Wicket.Ajax.ajax. This is what I see in firebug.
attrs {
c="grid6",
u="./?3-6.IBehaviorListene...ent-assetListTable-grid",
ep=[{action="cellClick"},
{key="8"},
{column="caseNumber"}
]
}
But on the server, in the behavior I do the following:
final IRequestParameters parms =
requestCycle.getRequest().getRequestParameters();
String val = parms.getParameterValue("action").toString();
val is null. So I must not be providing the parameters correctly. What am
I doing wrong? This seems to match the examples I see.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Invoke-Wicket-from-JavaSctipt-tp4664043.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: Wicket 6 - JavaScriptHeaderItem renders too early
For posterity, the solution that eventually worked for me: response.render(JavaScriptHeaderItem.forReference(new JavaScriptResourceReference(ExtGrid.class, "ExtGridSupport.js"))); response.render(OnDomReadyHeaderItem.forScript(writeGridJS())); The on dom ready delays my init long enough to serve my purposes. I never did get the filter solution working. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-JavaScriptHeaderItem-renders-too-early-tp4663910p4664042.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: Is there an equivalent for ResourceReference in wicket 6
Hello Martin, Thanks for the heads up, I'll definitely make that change in my project, Cheers -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-there-an-equivalent-for-ResourceReference-in-wicket-6-tp4664014p4664041.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: Teaming up remotely
I think the lesson here is that designers will never be programmers and programmers will never be designers but each needs to have a little of the other or the end result will be functionaly useless static web pages (in the case of designers) or functional pages that look like a dogs breakfast. Surely this issue comes up in other web frameworks. PHP for example. That would be even more broken from a designer perspective. I can't imagine trying to import a php script into dreamweaver or any other design tool? If dreamweaver can't deal with componentized markup sets something is seriously messed up. On 29/01/14 23:09, Nick Pratt wrote: > We found the simplest way to handle this situation was to let the HTML/CSS > folks design and style the page in pure HTML, no Wicket tags, with sample > data they made up. They then committed their changes into the shared VCS. > The designers Ive worked with in the past just didn't (or didn't want to) > understand the Wicket tags and their structure. We spent way too much time > fixing broken markup because the designers thought it was ok to or they > didnt realize they were moving tags around. The designers also dont run > Java unit tests so you dont catch page rendering errors until the markup > changes hit the Java devs desktops. After several attempts at explaining in > what scenarios Wicket tags couldnt be moved we gave up and had them run a > page or two in front of the Java devs. Converting plain HTML with sample > data into a Wicket page was far simpler and easier for the Java/Wicket > programmers than the other way around. > > Your mileage may vary ;-) > > > On Wed, Jan 29, 2014 at 3:54 AM, Lucio Crusca wrote: > >> Hello everybody, >> >> today I need to begin a project where, for the 1st time in my life, the >> team >> members won't work close to each other, and, again for the 1st time, I'm >> going >> to use Wicket in such a project. I'm in charge of writing all the code >> (mostly >> Java with Wicket being the framework of choice for the UI). The rest of the >> team is located about 700km from me and they're going to take care of HTML >> and >> CSS development. >> >> Are there any recognized best practices I should suggest them in HTML/CSS >> production in order to avoid problems on my side? E.g. is it usual asking >> for >> HTML files split into "common header for all pages", "common footer", >> "common >> whatever" and "page specific content" apart? Or is it more common to split >> them >> myself? >> >> How should we manage revisions? I could arrange for a bazaar server or the >> like, but how are those tools understood by web designers? Or should I take >> their files and manage conflicts and commits on my side without even >> telling >> them? But, then again, revision control works best on a line by line based >> comparison, and with Wicket I suspect conflicts will be the norm. E.g. >> suppose >> they change anything on their side in a HTML file that I already edited >> with >> wicket tags and committed to bzr: >> >> --- Their HTML file >> old: >> new: >> >> -- My HTML file >> committed: >> new: >> >> --> conflict (because they aren't aware of my edits and they can't be, >> unless >> they split HTML files in header, footer, whatever and use bzr themselves). >> >> I'm puzzled, that has to be a so common problem I hardly believe there's no >> standardized solution. Please advice. >> >> - >> 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: AjaxLazyLoadPanel loading asynchronously
Hi, I remember Igor posted and example of a non-blocking lazy load panel (long time ago). As far as I remember all it did was: 1-Check is results where ready is so render the panel 2-If not then schedule a timer to poll the panel again On Wed, Jan 29, 2014 at 1:28 PM, Vishal Popat wrote: > Hi, > > I have a situation where I have to make multiple REST calls to different > suppliers. > I currently am using AjaxLazyLoadPanel to make these calls but loading > time is very slow and not scaleable if I wanted to add more suppliers. > > Is there a way to make AjaxLazyLoadPanel asynchronously? > I have read some older posts on the forum but not sure if they are the > best way in Wicket 6. > Or is there an alternative approach? > > Many thanks > Vishal > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
Re: Teaming up remotely
We found the simplest way to handle this situation was to let the HTML/CSS folks design and style the page in pure HTML, no Wicket tags, with sample data they made up. They then committed their changes into the shared VCS. The designers Ive worked with in the past just didn't (or didn't want to) understand the Wicket tags and their structure. We spent way too much time fixing broken markup because the designers thought it was ok to or they didnt realize they were moving tags around. The designers also dont run Java unit tests so you dont catch page rendering errors until the markup changes hit the Java devs desktops. After several attempts at explaining in what scenarios Wicket tags couldnt be moved we gave up and had them run a page or two in front of the Java devs. Converting plain HTML with sample data into a Wicket page was far simpler and easier for the Java/Wicket programmers than the other way around. Your mileage may vary ;-) On Wed, Jan 29, 2014 at 3:54 AM, Lucio Crusca wrote: > Hello everybody, > > today I need to begin a project where, for the 1st time in my life, the > team > members won't work close to each other, and, again for the 1st time, I'm > going > to use Wicket in such a project. I'm in charge of writing all the code > (mostly > Java with Wicket being the framework of choice for the UI). The rest of the > team is located about 700km from me and they're going to take care of HTML > and > CSS development. > > Are there any recognized best practices I should suggest them in HTML/CSS > production in order to avoid problems on my side? E.g. is it usual asking > for > HTML files split into "common header for all pages", "common footer", > "common > whatever" and "page specific content" apart? Or is it more common to split > them > myself? > > How should we manage revisions? I could arrange for a bazaar server or the > like, but how are those tools understood by web designers? Or should I take > their files and manage conflicts and commits on my side without even > telling > them? But, then again, revision control works best on a line by line based > comparison, and with Wicket I suspect conflicts will be the norm. E.g. > suppose > they change anything on their side in a HTML file that I already edited > with > wicket tags and committed to bzr: > > --- Their HTML file > old: > new: > > -- My HTML file > committed: > new: > > --> conflict (because they aren't aware of my edits and they can't be, > unless > they split HTML files in header, footer, whatever and use bzr themselves). > > I'm puzzled, that has to be a so common problem I hardly believe there's no > standardized solution. Please advice. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
AjaxLazyLoadPanel loading asynchronously
Hi, I have a situation where I have to make multiple REST calls to different suppliers. I currently am using AjaxLazyLoadPanel to make these calls but loading time is very slow and not scaleable if I wanted to add more suppliers. Is there a way to make AjaxLazyLoadPanel asynchronously? I have read some older posts on the forum but not sure if they are the best way in Wicket 6. Or is there an alternative approach? Many thanks Vishal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Teaming up remotely
Sorry that my attemp to explain misled you thinking, that everything
should be one file.
Trying again...
Taking the case of a panel. I still think working on different aspects
of the file (design and logic) can be a non-conflicting business. From a
desinger's point of view, the markup file, that corresponds to the
panel's Java class, is a well-formed and completely self-contained HTML
page with all resources included to make the panel appear the way it
should and can be statically opened in a browser as it is (not only at
runtime).
Next, the developer adds the tag just around the section,
Wicket should apply the logic.
So you as a developer have not necessarily anything to do with what is
changed aside/inside/around the . So design and logic
should evolve (virtually) independent from each other.
I admit, this may lead to an amount of redundant markup code in the
repo. But it will be stripped of at runtime and the page wicket delivers
is as compact as it is needed.
Am 29.01.2014 11:47, schrieb Steve:
I'm not sure how the MarkupParser would handle multiple
tags in one file? How would it identify which instance of
belonged to which java Panel?
On 29/01/14 20:44, Lucio Crusca wrote:
In data mercoledì 29 gennaio 2014 10:57:59, tho...@jarnot.de ha
scritto:
Is there really a need of splitting up the markup files?
Well, I don't know, I mean, I've always split them up because a Wicket
webapp
is typically a collection of {1 java file, 1 html file by the same
name} tuples.
However I have to admit that I had already broke that pattern over
time and it
actually worked (e.g. derived java class but html file only for the
base
class).
Do you think it's feasible to drive that practice to the extreme of
having
only 1 html file per page and several derived java classes? I'm afraid
that
model would suffer from a serious impedance mismatch against the OOP
pattern,
because you can't have one single MyAppPage java base class, but you
are
forced to create several java classes for each HTML page and use just
panels
inclusion in each one. I'm not saying that's not possible, but seems
to me
it's not very OOP-ish. Am i wrong?
-
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: Teaming up remotely
I'm not sure how the MarkupParser would handle multiple
tags in one file? How would it identify which instance of
belonged to which java Panel?
On 29/01/14 20:44, Lucio Crusca wrote:
> In data mercoledì 29 gennaio 2014 10:57:59, tho...@jarnot.de ha scritto:
>> Is there really a need of splitting up the markup files?
> Well, I don't know, I mean, I've always split them up because a Wicket webapp
> is typically a collection of {1 java file, 1 html file by the same name}
> tuples.
>
> However I have to admit that I had already broke that pattern over time and
> it
> actually worked (e.g. derived java class but html file only for the base
> class).
>
> Do you think it's feasible to drive that practice to the extreme of having
> only 1 html file per page and several derived java classes? I'm afraid that
> model would suffer from a serious impedance mismatch against the OOP pattern,
> because you can't have one single MyAppPage java base class, but you are
> forced to create several java classes for each HTML page and use just panels
> inclusion in each one. I'm not saying that's not possible, but seems to me
> it's not very OOP-ish. Am i wrong?
>
>
>
> -
> 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: Teaming up remotely
In data mercoledì 29 gennaio 2014 10:57:59, tho...@jarnot.de ha scritto:
> Is there really a need of splitting up the markup files?
Well, I don't know, I mean, I've always split them up because a Wicket webapp
is typically a collection of {1 java file, 1 html file by the same name} tuples.
However I have to admit that I had already broke that pattern over time and it
actually worked (e.g. derived java class but html file only for the base
class).
Do you think it's feasible to drive that practice to the extreme of having
only 1 html file per page and several derived java classes? I'm afraid that
model would suffer from a serious impedance mismatch against the OOP pattern,
because you can't have one single MyAppPage java base class, but you are
forced to create several java classes for each HTML page and use just panels
inclusion in each one. I'm not saying that's not possible, but seems to me
it's not very OOP-ish. Am i wrong?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Can I get an input text value if it's not in a form?
Thanks. I wrapped the input in a form and used an ajax submit link. I could not figure out how can I send parameters from client by doing the work manually, but I will take a deeper look. Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Can-I-get-an-input-text-value-if-it-s-not-in-a-form-tp4663967p4664029.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
Which is recomended way to implemen an editable repeating view
Hello, I want to know which is the best way to implement a repeating view, preferable data view which contains an input field in each row. On submit, I need to get an iterator to get reference both to row model (example a Person object) and to editable component (ex an input text for age). The input must be processed and model updated. Thanks in advance. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Which-is-recomended-way-to-implemen-an-editable-repeating-view-tp4664028.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: Is there an equivalent for ResourceReference in wicket 6
Hi, Read http://wicketinaction.com/2012/07/wicket-6-resource-management/ I am not sure where you read that ResourceReference is removed. It is still around. @Simon: renderHead(HtmlHeaderContainer) is an internal thingy that is hidden from you in Wicket 7. You should use renderHead(IHeaderResponse) in your apps. Martin Grigorov Wicket Training and Consulting On Wed, Jan 29, 2014 at 10:56 AM, Simon B wrote: > Hello, > > I override the renderHead(HtmlHeaderContainer) method if its a Panel and > renderHead(IHeaderResponse) if its a WebPage : > > So in the case of a Panel, I guess it would be something like: > > > Hope that helps. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Is-there-an-equivalent-for-ResourceReference-in-wicket-6-tp4664014p4664024.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: Teaming up remotely
Am 29.01.2014 10:22, schrieb Lucio Crusca: In data mercoledì 29 gennaio 2014 19:06:09, Steve ha scritto: The difficulty I would think is when you start to split up html files to seperate sections into their own panels. If the designer only has a view of the markup it may not be obvious to them where the subsection of the html has gone. Sure you can explain the concept of Panels to them but to be certain that a certain wicked:id equates to particular panel type and find the right markup file you need to look at the java code. The problem is actually even worse than that: the moment I start splitting up HTML files, their web design suite stops recognizing them (I think this is common to every web design suite out there, no matter which one). So they are somewhat forced to work without my revision control system, because they just can't use the files anymore after my edits (unless someone suggests a better solution). Maybe I should impose a rigid deadline on HTML modifications, after which they must ask me to edit anything? E.g. they must work on HTML before giving it to me. After that they can work only on CSS and ask me to edit class="..." attributes as needed. Is this a reasonable solution? Is that even acceptable for designers? Just one thought. Wouldn't it be possible with Wicket, to leave all markup files as entirely "standalone" working (with all resources included) and just add your wicket:tags to the sections Wicket should work on? Is there really a need of splitting up the markup files? Eg. if you want to define a Wicket panel, just add your ignoring all the other HTML stuff, where the designer builds the panel ignoring all the Wicket stuff (?) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is there an equivalent for ResourceReference in wicket 6
Hello, I override the renderHead(HtmlHeaderContainer) method if its a Panel and renderHead(IHeaderResponse) if its a WebPage : So in the case of a Panel, I guess it would be something like: Hope that helps. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-there-an-equivalent-for-ResourceReference-in-wicket-6-tp4664014p4664024.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: Teaming up remotely
In data mercoledì 29 gennaio 2014 19:06:09, Steve ha scritto: > The difficulty I would think is when you start to split up html files to > seperate sections into their own panels. If the designer only has a > view of the markup it may not be obvious to them where the subsection of > the html has gone. Sure you can explain the concept of Panels to them > but to be certain that a certain wicked:id equates to particular panel > type and find the right markup file you need to look at the java code. The problem is actually even worse than that: the moment I start splitting up HTML files, their web design suite stops recognizing them (I think this is common to every web design suite out there, no matter which one). So they are somewhat forced to work without my revision control system, because they just can't use the files anymore after my edits (unless someone suggests a better solution). Maybe I should impose a rigid deadline on HTML modifications, after which they must ask me to edit anything? E.g. they must work on HTML before giving it to me. After that they can work only on CSS and ask me to edit class="..." attributes as needed. Is this a reasonable solution? Is that even acceptable for designers? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Teaming up remotely
I would think that using common version control and just telling them to ignore any wicket tags or wicket attributes they see after you've modified the markup. That part is not too hard for them to get their head around. The difficulty I would think is when you start to split up html files to seperate sections into their own panels. If the designer only has a view of the markup it may not be obvious to them where the subsection of the html has gone. Sure you can explain the concept of Panels to them but to be certain that a certain wicked:id equates to particular panel type and find the right markup file you need to look at the java code. I'm also very interested in answers to this problem. On 29/01/14 18:54, Lucio Crusca wrote: > Hello everybody, > > today I need to begin a project where, for the 1st time in my life, the team > members won't work close to each other, and, again for the 1st time, I'm > going > to use Wicket in such a project. I'm in charge of writing all the code > (mostly > Java with Wicket being the framework of choice for the UI). The rest of the > team is located about 700km from me and they're going to take care of HTML > and > CSS development. > > Are there any recognized best practices I should suggest them in HTML/CSS > production in order to avoid problems on my side? E.g. is it usual asking for > HTML files split into "common header for all pages", "common footer", "common > whatever" and "page specific content" apart? Or is it more common to split > them > myself? > > How should we manage revisions? I could arrange for a bazaar server or the > like, but how are those tools understood by web designers? Or should I take > their files and manage conflicts and commits on my side without even telling > them? But, then again, revision control works best on a line by line based > comparison, and with Wicket I suspect conflicts will be the norm. E.g. > suppose > they change anything on their side in a HTML file that I already edited with > wicket tags and committed to bzr: > > --- Their HTML file > old: > new: > > -- My HTML file > committed: > new: > > --> conflict (because they aren't aware of my edits and they can't be, unless > they split HTML files in header, footer, whatever and use bzr themselves). > > I'm puzzled, that has to be a so common problem I hardly believe there's no > standardized solution. Please advice. > > - > 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
Teaming up remotely
Hello everybody, today I need to begin a project where, for the 1st time in my life, the team members won't work close to each other, and, again for the 1st time, I'm going to use Wicket in such a project. I'm in charge of writing all the code (mostly Java with Wicket being the framework of choice for the UI). The rest of the team is located about 700km from me and they're going to take care of HTML and CSS development. Are there any recognized best practices I should suggest them in HTML/CSS production in order to avoid problems on my side? E.g. is it usual asking for HTML files split into "common header for all pages", "common footer", "common whatever" and "page specific content" apart? Or is it more common to split them myself? How should we manage revisions? I could arrange for a bazaar server or the like, but how are those tools understood by web designers? Or should I take their files and manage conflicts and commits on my side without even telling them? But, then again, revision control works best on a line by line based comparison, and with Wicket I suspect conflicts will be the norm. E.g. suppose they change anything on their side in a HTML file that I already edited with wicket tags and committed to bzr: --- Their HTML file old: new: -- My HTML file committed: new: --> conflict (because they aren't aware of my edits and they can't be, unless they split HTML files in header, footer, whatever and use bzr themselves). I'm puzzled, that has to be a so common problem I hardly believe there's no standardized solution. Please advice. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
