Programmatically change an HTML attribute value.
Hi, I'm assuming this is a dumb question but I wasn't able to locate an answer for what must be an extremely common need. I found the docs on How to modify an attribute on a HTML tag but that doesn't quite fit, as the examples are all for elements that are themselves created programmatically. Mine is solely in markup. I've got a lot of HTML markup surrounded by a div element. The div element isn't created via Wicket, it's in my HTML file. It has a fair bit of descendent content so I don't want to have to create that via Java, as I'm assuming if I put a wicket:id on the div element that would replace everything within the div. I just want to programmatically alter its 'class' attribute, but I don't see how this is accomplished. E.g., div class=foo table ... etc. /table /div This would effectively be some kind of query to locate the div element, then a modification of its 'class' attribute. Alternately, if I am required to create the div element programmatically, how I attach a whole lot of HTML markup to it? Do I have to use a fragment? That seems like a lot of work to just alter an attribute value, so like I said, I must be missing something obvious here... Ichiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Programmatically change an HTML attribute value.
Hmm. Thanks for the answers guys but from what I've understand
so far from my own digging and your answers is that the container
div I want to modify still needs to be created programmatically,
and I'm distinctly trying to modify the attribute of one that begins its
life in markup (i.e., in the .html file, not the .java file).
It seems that may not be possible in Wicket so I'll probably have to
push the contained markup into a fragment and add it to a
programmatically-created element. Not quite what I wanted (and
more complicated than I'd prefer) but doable.
It's a shame something that can be accomplished with a simple
DOM manipulation (get element by ID, then set its attribute value)
ends up being fairly complicated.
Thanks!
Ichiro
On 10/1/10, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote:
How about using a WebMarkupContainer?
Then you can use an attribute modifier like the below example to set the
class value.
All you have to do is make the new component heirarchy match the markup
heirarchy.
div wicket:id=styler class=foo
table
form wicket:id=form
...
/form
/table
/div
In your panel you go from:
add (new Form (form));
...
to:
WebMarkupContainer c = new WebMarkupContainer (styler);
c.add (new AttributeModifier (class, true, new ModelString(even)));
add (c);
c.add (new Form(form));
Another option might be to use a border to add the wrapping div and
class attribute.
Regards,
Mike
Hi Ichiro,
This is what I use in a ListView to change the style attribute of table
rows to give alternate colours to them.
code
item.add(new AttributeModifier(class, true, new
AbstractReadOnlyModelString()
{
@Override
public String getObject()
{
return (item.getIndex() % 2 == 1) ? even :
odd;
}
}));
/code
I think you can add attributes like this to any component.
On Fri, Oct 1, 2010 at 8:23 AM, James
Carmanja...@carmanconsulting.comwrote:
AttributeModifier
On Sep 30, 2010 8:07 PM, Ichiro Furusatoichiro.furus...@gmail.com
wrote:
Hi,
I'm assuming this is a dumb question but I wasn't able to locate an
answer
for what must be an extremely common need. I found the docs on How to
modify an attribute on a HTML tag but that doesn't quite fit, as the
examples
are all for elements that are themselves created programmatically. Mine
is
solely in markup.
I've got a lot of HTML markup surrounded by adiv element. Thediv
element isn't created via Wicket, it's in my HTML file. It has a fair
bit
of
descendent content so I don't want to have to create that via Java, as
I'm assuming if I put a wicket:id on thediv element that would
replace
everything within thediv. I just want to programmatically alter its
'class'
attribute, but I don't see how this is accomplished.
E.g.,
div class=foo
table
... etc.
/table
/div
This would effectively be some kind of query to locate thediv
element,
then a modification of its 'class' attribute.
Alternately, if I am required to create thediv element
programmatically,
how I attach a whole lot of HTML markup to it? Do I have to use a
fragment?
That seems like a lot of work to just alter an attribute value, so like
I
said,
I must be missing something obvious here...
Ichiro
-
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: Programmatically change an HTML attribute value.
Ack, sorry, I managed to figure it out via Michael's suggestion.
Here's the result. This show the relevant parts of embedding a
userpanel into a templatepage:
TemplatePage.html:
div id=userdiv wicket:id=userdiv
div id=user wicket:id=useruser/div
/div!-- end user --
TemplatePage.java:
WebMarkupContainer c = new WebMarkupContainer(userdiv);
c.add(new AttributeModifier(class,true,new ModelString(even)));
add(c);
c.add(new UserPanel(user));
The resulting markup:
div id=userdiv class=even
div id=user!-- begin user . --
...
/div
/div!-- end user --
and I'm able to programmatically alter the value of the
'class' attribute on the userdiv (wrapper div) element.
It was a bit more complicated than I'd wished, but not
onerously so, and frankly not much more code than
using the DOM.
Thanks very much guys!
Ichiro
On 10/1/10, Ichiro Furusato ichiro.furus...@gmail.com wrote:
Hmm. Thanks for the answers guys but from what I've understand
so far from my own digging and your answers is that the container
div I want to modify still needs to be created programmatically,
and I'm distinctly trying to modify the attribute of one that begins its
life in markup (i.e., in the .html file, not the .java file).
It seems that may not be possible in Wicket so I'll probably have to
push the contained markup into a fragment and add it to a
programmatically-created element. Not quite what I wanted (and
more complicated than I'd prefer) but doable.
It's a shame something that can be accomplished with a simple
DOM manipulation (get element by ID, then set its attribute value)
ends up being fairly complicated.
Thanks!
Ichiro
On 10/1/10, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote:
How about using a WebMarkupContainer?
Then you can use an attribute modifier like the below example to set the
class value.
All you have to do is make the new component heirarchy match the markup
heirarchy.
div wicket:id=styler class=foo
table
form wicket:id=form
...
/form
/table
/div
In your panel you go from:
add (new Form (form));
...
to:
WebMarkupContainer c = new WebMarkupContainer (styler);
c.add (new AttributeModifier (class, true, new ModelString(even)));
add (c);
c.add (new Form(form));
Another option might be to use a border to add the wrapping div and
class attribute.
Regards,
Mike
Hi Ichiro,
This is what I use in a ListView to change the style attribute of
table
rows to give alternate colours to them.
code
item.add(new AttributeModifier(class, true, new
AbstractReadOnlyModelString()
{
@Override
public String getObject()
{
return (item.getIndex() % 2 == 1) ? even :
odd;
}
}));
/code
I think you can add attributes like this to any component.
On Fri, Oct 1, 2010 at 8:23 AM, James
Carmanja...@carmanconsulting.comwrote:
AttributeModifier
On Sep 30, 2010 8:07 PM, Ichiro Furusatoichiro.furus...@gmail.com
wrote:
Hi,
I'm assuming this is a dumb question but I wasn't able to locate an
answer
for what must be an extremely common need. I found the docs on How to
modify an attribute on a HTML tag but that doesn't quite fit, as the
examples
are all for elements that are themselves created programmatically.
Mine
is
solely in markup.
I've got a lot of HTML markup surrounded by adiv element. Thediv
element isn't created via Wicket, it's in my HTML file. It has a fair
bit
of
descendent content so I don't want to have to create that via Java, as
I'm assuming if I put a wicket:id on thediv element that would
replace
everything within thediv. I just want to programmatically alter its
'class'
attribute, but I don't see how this is accomplished.
E.g.,
div class=foo
table
... etc.
/table
/div
This would effectively be some kind of query to locate thediv
element,
then a modification of its 'class' attribute.
Alternately, if I am required to create thediv element
programmatically,
how I attach a whole lot of HTML markup to it? Do I have to use a
fragment?
That seems like a lot of work to just alter an attribute value, so
like
I
said,
I must be missing something obvious here...
Ichiro
-
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: Modular XHTML DTD for Wicket?
Hi Erik, I'll begin working with this over the weekend, and will post a notice when I have something to show. If I have any specific questions I'll ask the list -- this will likely be an iterative process... Cheers, Ichiro On 9/28/10, Erik van Oosten e.vanoos...@grons.nl wrote: Hello Ichiro, Bring it on! Find all xhtml tags here: https://cwiki.apache.org/WICKET/wickets-xhtml-tags.html. Here you will also find a link to the current DTDs. Regards, Erik. Op 28-09-10 04:53, Ichiro Furusato schreef: I brought this up previously under Wicket pages are invalid XHTML on Thu, 16 Sep 2010 13:11:06 +1200 but the conversation got sidetracked by a solution to a question I'd asked without addressing an offer I'd made. Would anyone be interested in replacing the misnamed and incomplete XHTML DTD used by the Wicket project with a modular XHTML DTD that had its own Wicket module? This could be used to validate Wicket-ised documents. I'm versed in building modular DTDs using the W3C toolkit. (I note WICKET-693 exists) and can also flatten the DTD to a single file using a tool I have. I'd be willing to supply that DTD if someone could provide documentation on the extant wicket elements and attributes, and where in the document model they are permitted. If this is something properly directed at the Wicket dev list let me know and I'll resend it there (I'm not currently a member of that list). Or if this isn't a priority for the project (it may not be if well-formed XML is sufficient during dev) I'll drop the issue. Thanks, Ichiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/ - 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
Modular XHTML DTD for Wicket?
I brought this up previously under Wicket pages are invalid XHTML on Thu, 16 Sep 2010 13:11:06 +1200 but the conversation got sidetracked by a solution to a question I'd asked without addressing an offer I'd made. Would anyone be interested in replacing the misnamed and incomplete XHTML DTD used by the Wicket project with a modular XHTML DTD that had its own Wicket module? This could be used to validate Wicket-ised documents. I'm versed in building modular DTDs using the W3C toolkit. (I note WICKET-693 exists) and can also flatten the DTD to a single file using a tool I have. I'd be willing to supply that DTD if someone could provide documentation on the extant wicket elements and attributes, and where in the document model they are permitted. If this is something properly directed at the Wicket dev list let me know and I'll resend it there (I'm not currently a member of that list). Or if this isn't a priority for the project (it may not be if well-formed XML is sufficient during dev) I'll drop the issue. Thanks, Ichiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket serving DocBook?
Hi, I'm not asking anyone to solve this one (ie., write any code), just tell me *how* it might be done via Wicket, if it's possible. In one of my earlier messages regarding validation of Wicket pages, Jeremy Thomerson replied that Wicket only generates whatever HTML you want it to generate and that got me thinking, why generate HTML (or XHTML) at all? Why not use Wicket as a means of generating something like DocBook or TEI? This raises two questions: 1. In looking into the Wicket code there are places that mention HTML/XHTML markup, but they don't seem part of the core functionality of Wicket. Is there anything that might keep me from generating DocBook instead of HTML? If Wicket is too tied into HTML (e.g., org.apache.wicket.markup.html.*) to be able to do this, what would it take to abstract the HTML-based functionality so that Wicket could serve any XML markup? 2. If I were going to use the above to generate DocBook with the idea that Wicket's servlet then sent that through an XSLT post-processor, would this *only* require changes to the Wicket servlet prior to fulfilling the servlet response? That *seems* to be the case, but I'm still learning Wicket. Basically, one could conceivably use Wicket in this mode as a replacement for Apache Cocoon, but it'd be *much* simpler and potentially very powerful. Just an idea I'm exploring... would potentially have wide usage. Thanks much! Ichiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Job opportunity in Tahiti
Damn, I wish I spoke French! :-) On 9/25/10, Emmanouil Batsis (Manos) ma...@abiss.gr wrote: On 09/24/2010 10:35 PM, Gabriel Landon wrote: Our client wants a CMS, so we have chosen to use Liferay. Liferay is a java portal, so we need to use portlets with it. That as simple as that. When we don't need a CMS, we just do simple wicket application. Not that it's any of my business, but it's nice to have options. For example, I might go with BRIX or whatnot if the developers under consideration had serious experience with it ;-) Just my 0.2. -- Manos Batsis, Chief Technologist ___ _/ /_ (_)_ __ / __ `/ __ \/ / ___/ ___// __ `/ ___/ / /_/ / /_/ / (__ |__ )/ /_/ / / \__,_/_.___/_//(_)__, /_/ // http://www.Abiss.gr 19, Kalvou Street, 14231, Nea Ionia, Athens, Greece Tel: +30 211-1027-900 Fax: +30 211-1027-999 http://gr.linkedin.com/in/manosbatsis - 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 serving DocBook?
Hi Ernesto,
Yes, that was the plan (in terms of delivering DocBook), I just
wasn't sure how tightly Wicket is itself tied to HTML. I hadn't
thought of Igor's suggestion (being new to Wicket) so I'll check
out how to add behaviours (didn't realise it could be that simple,
though with Wicket I shouldn't be too surprised) --but this
sounds like a plan...
Thanks much,
Ichiro
On 9/25/10, Igor Vaynberg igor.vaynb...@gmail.com wrote:
or dump docbook into a label and add an xslt transformer behavior to the
label.
-igor
On Fri, Sep 24, 2010 at 6:54 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Ichiro,
Can't you just override
public String getMarkupType()
{
return html;
}
on WebPage class and return xml and generate whatever (well formed)
XML you need? Besides that you could put a filter in front of that
page and do whatever post-processing you need.
Regards,
Ernesto
On Fri, Sep 24, 2010 at 3:00 PM, Ichiro Furusato
ichiro.furus...@gmail.com wrote:
Hi,
I'm not asking anyone to solve this one (ie., write any code), just
tell me *how* it might be done via Wicket, if it's possible.
In one of my earlier messages regarding validation of Wicket
pages, Jeremy Thomerson replied that Wicket only generates
whatever HTML you want it to generate and that got me thinking,
why generate HTML (or XHTML) at all? Why not use Wicket as a
means of generating something like DocBook or TEI?
This raises two questions:
1. In looking into the Wicket code there are places that mention
HTML/XHTML markup, but they don't seem part of the core
functionality of Wicket. Is there anything that might keep me
from generating DocBook instead of HTML? If Wicket is too
tied into HTML (e.g., org.apache.wicket.markup.html.*) to be
able to do this, what would it take to abstract the HTML-based
functionality so that Wicket could serve any XML markup?
2. If I were going to use the above to generate DocBook with
the idea that Wicket's servlet then sent that through an
XSLT post-processor, would this *only* require changes to
the Wicket servlet prior to fulfilling the servlet response?
That *seems* to be the case, but I'm still learning Wicket.
Basically, one could conceivably use Wicket in this mode as a
replacement for Apache Cocoon, but it'd be *much* simpler
and potentially very powerful.
Just an idea I'm exploring... would potentially have wide usage.
Thanks much!
Ichiro
-
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: Wicket serving DocBook?
Hah! Just found XsltTransformerBehavior. I'm now thinking
about an XML database web service, lots of possibilities.
Wicket may have a lot of more general-purpose XML application.
Hmmm...
On 9/25/10, Ichiro Furusato ichiro.furus...@gmail.com wrote:
Hi Ernesto,
Yes, that was the plan (in terms of delivering DocBook), I just
wasn't sure how tightly Wicket is itself tied to HTML. I hadn't
thought of Igor's suggestion (being new to Wicket) so I'll check
out how to add behaviours (didn't realise it could be that simple,
though with Wicket I shouldn't be too surprised) --but this
sounds like a plan...
Thanks much,
Ichiro
On 9/25/10, Igor Vaynberg igor.vaynb...@gmail.com wrote:
or dump docbook into a label and add an xslt transformer behavior to the
label.
-igor
On Fri, Sep 24, 2010 at 6:54 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Ichiro,
Can't you just override
public String getMarkupType()
{
return html;
}
on WebPage class and return xml and generate whatever (well formed)
XML you need? Besides that you could put a filter in front of that
page and do whatever post-processing you need.
Regards,
Ernesto
On Fri, Sep 24, 2010 at 3:00 PM, Ichiro Furusato
ichiro.furus...@gmail.com wrote:
Hi,
I'm not asking anyone to solve this one (ie., write any code), just
tell me *how* it might be done via Wicket, if it's possible.
In one of my earlier messages regarding validation of Wicket
pages, Jeremy Thomerson replied that Wicket only generates
whatever HTML you want it to generate and that got me thinking,
why generate HTML (or XHTML) at all? Why not use Wicket as a
means of generating something like DocBook or TEI?
This raises two questions:
1. In looking into the Wicket code there are places that mention
HTML/XHTML markup, but they don't seem part of the core
functionality of Wicket. Is there anything that might keep me
from generating DocBook instead of HTML? If Wicket is too
tied into HTML (e.g., org.apache.wicket.markup.html.*) to be
able to do this, what would it take to abstract the HTML-based
functionality so that Wicket could serve any XML markup?
2. If I were going to use the above to generate DocBook with
the idea that Wicket's servlet then sent that through an
XSLT post-processor, would this *only* require changes to
the Wicket servlet prior to fulfilling the servlet response?
That *seems* to be the case, but I'm still learning Wicket.
Basically, one could conceivably use Wicket in this mode as a
replacement for Apache Cocoon, but it'd be *much* simpler
and potentially very powerful.
Just an idea I'm exploring... would potentially have wide usage.
Thanks much!
Ichiro
-
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: Wicket serving DocBook?
Oh, believe me, I already have a few nails in mind...
On 9/25/10, James Carman ja...@carmanconsulting.com wrote:
Sounds like a hammer looking for a nail
On Fri, Sep 24, 2010 at 7:38 PM, Ichiro Furusato
ichiro.furus...@gmail.com wrote:
Hah! Just found XsltTransformerBehavior. I'm now thinking
about an XML database web service, lots of possibilities.
Wicket may have a lot of more general-purpose XML application.
Hmmm...
On 9/25/10, Ichiro Furusato ichiro.furus...@gmail.com wrote:
Hi Ernesto,
Yes, that was the plan (in terms of delivering DocBook), I just
wasn't sure how tightly Wicket is itself tied to HTML. I hadn't
thought of Igor's suggestion (being new to Wicket) so I'll check
out how to add behaviours (didn't realise it could be that simple,
though with Wicket I shouldn't be too surprised) --but this
sounds like a plan...
Thanks much,
Ichiro
On 9/25/10, Igor Vaynberg igor.vaynb...@gmail.com wrote:
or dump docbook into a label and add an xslt transformer behavior to the
label.
-igor
On Fri, Sep 24, 2010 at 6:54 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Ichiro,
Can't you just override
public String getMarkupType()
{
return html;
}
on WebPage class and return xml and generate whatever (well formed)
XML you need? Besides that you could put a filter in front of that
page and do whatever post-processing you need.
Regards,
Ernesto
On Fri, Sep 24, 2010 at 3:00 PM, Ichiro Furusato
ichiro.furus...@gmail.com wrote:
Hi,
I'm not asking anyone to solve this one (ie., write any code), just
tell me *how* it might be done via Wicket, if it's possible.
In one of my earlier messages regarding validation of Wicket
pages, Jeremy Thomerson replied that Wicket only generates
whatever HTML you want it to generate and that got me thinking,
why generate HTML (or XHTML) at all? Why not use Wicket as a
means of generating something like DocBook or TEI?
This raises two questions:
1. In looking into the Wicket code there are places that mention
HTML/XHTML markup, but they don't seem part of the core
functionality of Wicket. Is there anything that might keep me
from generating DocBook instead of HTML? If Wicket is too
tied into HTML (e.g., org.apache.wicket.markup.html.*) to be
able to do this, what would it take to abstract the HTML-based
functionality so that Wicket could serve any XML markup?
2. If I were going to use the above to generate DocBook with
the idea that Wicket's servlet then sent that through an
XSLT post-processor, would this *only* require changes to
the Wicket servlet prior to fulfilling the servlet response?
That *seems* to be the case, but I'm still learning Wicket.
Basically, one could conceivably use Wicket in this mode as a
replacement for Apache Cocoon, but it'd be *much* simpler
and potentially very powerful.
Just an idea I'm exploring... would potentially have wide usage.
Thanks much!
Ichiro
-
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
-
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
The Long, Long Dependency Trail
Hello, I've been working with Wicket for about a week now and things were moving along all cruisy until I started adding Hibernate and Databinder dependencies into my POM. Then all hell broke loose and I seem to now find myself in the NoClassDefFoundError, then find and manually install jar cycle. I mean, things with Wicket were just so, well, SENSIBLE, and now I'm back in nightmare-programming-land again. In looking at some of the examples on the Web that combine Wicket and Hibernate, they don't seem to be needing anywhere near the number of dependencies I am now adding. I'm guessing I must be doing something wrong, as I'm still pretty new to Maven, being a longstanding Ant person. That I've had to manually install a whole bunch (6) of jars seems a clue. Part of this may be due to the folks who wrote Databinder using git rather than a maven repository (why oh why?!). My application extends net.databinder.auth.hib.AuthDataApplication so that it can be an authenticating database application. I've attached both the latest stack trace and my pom.xml file in hopes that some kind soul can tell me where I've gone terribly wrong. Perhaps I'm almost at the end of the dependency tunnel but I'm not yet seeing any light yet. I'm guessing this is probably a blaringly obvious problem, or maybe not a problem at all and I'm almost there. Thanks very much, Ichiro PS. BTW, I'm really enjoying Wicket so far; I haven't had this much fun programming since HyperCard. I hope it's not significantly more complicated a year or two from now than it is now. If the developer team can keep to that ethos of simplicity Wicket will only gain in popularity. Avoid the bloat. --- Test set: net.neocortext.web.TestHomePage --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.225 sec FAILURE! testRenderMyPage(net.neocortext.web.TestHomePage) Time elapsed: 0.182 sec ERROR! java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/MetadataProvider at net.databinder.hib.DataApplication.buildHibernateSessionFactory(DataApplication.java:88) at net.databinder.hib.DataApplication.dataInit(DataApplication.java:56) at net.databinder.DataApplicationBase.internalInit(DataApplicationBase.java:54) at net.databinder.auth.hib.AuthDataApplication.internalInit(AuthDataApplication.java:74) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:721) at org.apache.wicket.protocol.http.MockWebApplication.init(MockWebApplication.java:168) at org.apache.wicket.util.tester.BaseWicketTester.init(BaseWicketTester.java:218) at org.apache.wicket.util.tester.WicketTester.init(WicketTester.java:331) at org.apache.wicket.util.tester.WicketTester.init(WicketTester.java:314) at net.neocortext.web.TestHomePage.setUp(TestHomePage.java:19) at junit.framework.TestCase.runBare(TestCase.java:128) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: java.lang.ClassNotFoundException: org.hibernate.annotations.common.reflection.MetadataProvider at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at
Re: The Long, Long Dependency Trail
Thanks very much all for your helpful replies. I'll try to answer all at once: Josh, I'm using Hibernate 3.5.6-Final. I'm going to clean out my .m2 repository of the Hibernate stuff, then try Bas' suggestion and see if it works without me having to manually install the jars to my local repository as I've done. Martijn, that sounds like a good suggestion in a sense, but I'm honestly trying to keep things as simple as possible (for future maintainability given I might not be the one working on this project next year), so hopefully I'll be able to get a pom.xml file together that does everything necessary without needing any local manager. But that's a good idea for my own stuff (i.e., at home) so I might give that a try. Thanks. Sebastian, just yesterday I tried letting Eclipse manage my dependencies using Maven (since this project uses Maven) and it seems sensible enough, just a different process and place to look to manage my external libraries. Thomas, prior to this project I used Ant exclusively, so that kind of thing is certainly the way to go, and it scales fine to lots of jars. You can get pretty tricky with Ant, and it's great for managing the jar/war metadata, signing jars, etc., lots of things I don't know how to do in Maven (assuming they call can be done -- this remains to be seen). Don, I've been tempted to looking into Ivy for a long time, and if it weren't for the fact that the Wicket project seems pretty Maven-centric (even acknowledging that they state that Maven is not strictly required), I'd probaby go back to Ant and use Ivy for my dependencies. I still may in the end. As I mentioned above, there's things I know how to do in Ant that I may want to accomplish without having to learn how in Maven. I still think Ant is pretty amazing really. With Ivy it might be a complete solution for me (I'm not one to use new software just because it's a popular fad, unless it's actually an improvement over what I'm already doing). Finally, thanks Nino, it turns out that I actually did use an archetype to generate the beginnings of this project, which is certainly one thing in Maven I do like. Postscript: I added the maven repository as suggested by Bas, backed all the Databinder stuff back to 1.3.0 so that I didn't need the SNAPSHOTs (and thereby fixed a bug due to a class that is no longer used), and stopped trying to use AuthDataApplication as my base class (using just DataApplication) since I'm using wicket-auth-roles and already had my own role-based auth classes in place. So now it works and has Hibernate and Databinder in the app. Next step: start building the database classes. Thanks all, this was very helpful. Ichiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [RELEASE] WASP/SWARM/Wicket security 1.4.1 released, roadmap for future direction
I haven't been following this that closely (I've only been acquainted with Wicket for a few days) but on installing Wasp and Swarm and then (on learning it wouldn't be a final solution) giving up on it to go back to wicket-auth-roles as a simpler solution, might there be another possibility? Why not work on finalising a wicket-security package that is comprised on a security API (with no implementation), then have Wasp, Swarm, some kind of Spring bridge, etc. as competing implementations? That would permit a stable security solution to be provided via API whilst not polluting the core with an unproven solution, or with a solution that will always have application-specific alternatives. Just an idea anyway. As to name, please choose one that isn't too cute. It doesn't have to be a brand, just a recognisable name or just an acronym with a reasonable explication. Ichiro On 9/17/10, Martijn Dashorst martijn.dasho...@gmail.com wrote: The Wicket Security project WASP/SWARM has released a new version: 1.4.1 News worthy changes: * Moved code from SwarmStrategy to AbstractSwarmStrategy to allow reuse with different implementations * Logout now uses Session.invalidate() instead of invalidateNow(), to prevent problems with the request logger * Spring example is now based on Spring 3 * Wicket dependency upgraded to 1.4.12 You can download the release from the Wicket stuff repository: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket-security/ Or upgrade using the following in your pom: dependency groupIdorg.apache.wicket.wicket-security/groupId artifactIdswarm/artifactId version1.4.1/version /dependency ROADMAP Milestone 1.5-M1 As Wicket Security will not be adopted into core, we'll be changing the package name and project name going forward. We're still not sure about the final name, but these two are the runners up: - Chitin - Wicket Keeper Both are nice names, and both have their pros and cons. Let us know which one you prefer. Furthermore we'll be adding new annotations such that you'll be able to authorize your pages using a Java class (for the principal) and an annotation on your page to specify which principals are required. This will eliminate the need for the policy files. Future milestones * Support for Wicket 1.5 * A new home * Deployment to maven central instead of wicketstuff repo We expect to release the first milestone in a week or so. - 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 pages are invalid XHTML
Thanks Emond, that looks very helpful. I'm a bit overwhelmed at this point, having started learning Wicket on Wednesday and by now almost having a bare bones application. Nice little surprises along the way... On 9/17/10, Emond Papegaaij emond.papega...@topicus.nl wrote: Hi Ichiro, If you want to enforce valid XHTML, take a look at the WicketStuff HTML Validator: http://github.com/dashorst/wicket-stuff-markup-validator It automatically validates all pages served by the application and shows an error report for invalid markup. Best regards, Emond Papegaaij On Thursday 16 September 2010 03:50:35 Ichiro Furusato wrote: Hi Jeremy, Thanks for the quick reply. Is the reason I'm seeing the wicket:id in my output then that I'm working in development mode? If so, I'd say that was a nice design decision (not surprising from what else I've seen in Wicket). Cheers, Ichiro On 9/16/10, Jeremy Thomerson jer...@wickettraining.com wrote: On Wed, Sep 15, 2010 at 8:11 PM, Ichiro Furusato ichiro.furus...@gmail.comwrote: Hi, I'm a new Wicket user and am unclear about a couple of things regarding what type of markup Wicket delivers to clients. Because some of the clients I work with have government guidelines restricting what document types are permitted (typically XHTML 1.0 Strict or Transitional), I'm concerned I might not be able to use Wicket for those projects. What I'll call the Wicket XHTML DTD is referenced as the XML namespace URI for wicket documents. As (from what I've seen) there is no stated DOCTYPE declaration, Wicket pages are expressed as well-formed XML only, even though they could likely validate according to the Wicket XHTML DTD. Unfortunately, for my applications I have a requirement to declare and be valid according to a W3C XHTML 1.0 DTD. It would seem from the unmodified comments found at the top of the Wicket XHTML DTD that the schema used at first glance is XHTML 1.0 Strict, e.g.: This DTD module is identified by the PUBLIC and SYSTEM identifiers: PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN SYSTEM http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; but on further investigation there have been modifications to the schema: the addition of some wicket: prefixed attributes to %coreattrs;. It's not industry practice to do that kind of thing, i.e., the header comments should identify the schema being expressed. If a DTD is modified the comments should be modified to relabel the schema. Any reference to the FPI (formal public identifier) for XHTML 1.0 would likewise be inappropriate since the Wicket schema has modified it. Even if the changes occur in a new XML namespace the schema is no longer XHTML 1.0 Strict and will not validate according to that DTD. There are a few questions/comments that come from the above: 1. Are the wicket attributes required for Wicket-based processing? Would removing them break existing functionality? 2. If the answer to #1 is no, could the web pages be run through a simple XSLT transform to remove the non-XHTML attributes? 3. If the answer to #2 is yes, I'm willing to supply the XSLT stylesheet, but I'm not on the developer team and couldn't based on my current workload volunteer, so I wouldn't be able to supply the code supporting that feature. 4. I am familiar with the XHTML modular DTDs and would be willing to supply an XHTML 1.0 DTD based on a new Wicket module, then flattened (converted into one file) based on some tools I've written. This would be a replacement for the existing Wicket XHTML DTD and be appropriately named, e.g., -//Apache.org//DTD XHTML 1.0 Strict for Wicket 1.4//EN This DTD could of course be used to validate Wicket-produced web pages, but wouldn't be needed if the wicket: attributes were stripped from generated web pages. Ideally, Wicket would produce valid XHTML 1.0 Strict. I don't know if this is possible. Some clarification on this would be most appreciated, Thanks, Ichiro PS. on the whole I'm liking what I see with Wicket, esp. compared to Spring's increasingly complex, arcane and fragile approach to what should not be rocket science. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org Wicket only generates whatever HTML you want it to generate. The only wicket tag (or actually, attribute) you are required to use is wicket:id, which will automatically be removed from your HTML in deployment mode. So, use strict XHTML in your *.html files and strict XHTML is what will be rendered. -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe
Wicket pages are invalid XHTML
Hi, I'm a new Wicket user and am unclear about a couple of things regarding what type of markup Wicket delivers to clients. Because some of the clients I work with have government guidelines restricting what document types are permitted (typically XHTML 1.0 Strict or Transitional), I'm concerned I might not be able to use Wicket for those projects. What I'll call the Wicket XHTML DTD is referenced as the XML namespace URI for wicket documents. As (from what I've seen) there is no stated DOCTYPE declaration, Wicket pages are expressed as well-formed XML only, even though they could likely validate according to the Wicket XHTML DTD. Unfortunately, for my applications I have a requirement to declare and be valid according to a W3C XHTML 1.0 DTD. It would seem from the unmodified comments found at the top of the Wicket XHTML DTD that the schema used at first glance is XHTML 1.0 Strict, e.g.: This DTD module is identified by the PUBLIC and SYSTEM identifiers: PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN SYSTEM http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; but on further investigation there have been modifications to the schema: the addition of some wicket: prefixed attributes to %coreattrs;. It's not industry practice to do that kind of thing, i.e., the header comments should identify the schema being expressed. If a DTD is modified the comments should be modified to relabel the schema. Any reference to the FPI (formal public identifier) for XHTML 1.0 would likewise be inappropriate since the Wicket schema has modified it. Even if the changes occur in a new XML namespace the schema is no longer XHTML 1.0 Strict and will not validate according to that DTD. There are a few questions/comments that come from the above: 1. Are the wicket attributes required for Wicket-based processing? Would removing them break existing functionality? 2. If the answer to #1 is no, could the web pages be run through a simple XSLT transform to remove the non-XHTML attributes? 3. If the answer to #2 is yes, I'm willing to supply the XSLT stylesheet, but I'm not on the developer team and couldn't based on my current workload volunteer, so I wouldn't be able to supply the code supporting that feature. 4. I am familiar with the XHTML modular DTDs and would be willing to supply an XHTML 1.0 DTD based on a new Wicket module, then flattened (converted into one file) based on some tools I've written. This would be a replacement for the existing Wicket XHTML DTD and be appropriately named, e.g., -//Apache.org//DTD XHTML 1.0 Strict for Wicket 1.4//EN This DTD could of course be used to validate Wicket-produced web pages, but wouldn't be needed if the wicket: attributes were stripped from generated web pages. Ideally, Wicket would produce valid XHTML 1.0 Strict. I don't know if this is possible. Some clarification on this would be most appreciated, Thanks, Ichiro PS. on the whole I'm liking what I see with Wicket, esp. compared to Spring's increasingly complex, arcane and fragile approach to what should not be rocket science. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket pages are invalid XHTML
Hi Jeremy, Thanks for the quick reply. Is the reason I'm seeing the wicket:id in my output then that I'm working in development mode? If so, I'd say that was a nice design decision (not surprising from what else I've seen in Wicket). Cheers, Ichiro On 9/16/10, Jeremy Thomerson jer...@wickettraining.com wrote: On Wed, Sep 15, 2010 at 8:11 PM, Ichiro Furusato ichiro.furus...@gmail.comwrote: Hi, I'm a new Wicket user and am unclear about a couple of things regarding what type of markup Wicket delivers to clients. Because some of the clients I work with have government guidelines restricting what document types are permitted (typically XHTML 1.0 Strict or Transitional), I'm concerned I might not be able to use Wicket for those projects. What I'll call the Wicket XHTML DTD is referenced as the XML namespace URI for wicket documents. As (from what I've seen) there is no stated DOCTYPE declaration, Wicket pages are expressed as well-formed XML only, even though they could likely validate according to the Wicket XHTML DTD. Unfortunately, for my applications I have a requirement to declare and be valid according to a W3C XHTML 1.0 DTD. It would seem from the unmodified comments found at the top of the Wicket XHTML DTD that the schema used at first glance is XHTML 1.0 Strict, e.g.: This DTD module is identified by the PUBLIC and SYSTEM identifiers: PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN SYSTEM http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; but on further investigation there have been modifications to the schema: the addition of some wicket: prefixed attributes to %coreattrs;. It's not industry practice to do that kind of thing, i.e., the header comments should identify the schema being expressed. If a DTD is modified the comments should be modified to relabel the schema. Any reference to the FPI (formal public identifier) for XHTML 1.0 would likewise be inappropriate since the Wicket schema has modified it. Even if the changes occur in a new XML namespace the schema is no longer XHTML 1.0 Strict and will not validate according to that DTD. There are a few questions/comments that come from the above: 1. Are the wicket attributes required for Wicket-based processing? Would removing them break existing functionality? 2. If the answer to #1 is no, could the web pages be run through a simple XSLT transform to remove the non-XHTML attributes? 3. If the answer to #2 is yes, I'm willing to supply the XSLT stylesheet, but I'm not on the developer team and couldn't based on my current workload volunteer, so I wouldn't be able to supply the code supporting that feature. 4. I am familiar with the XHTML modular DTDs and would be willing to supply an XHTML 1.0 DTD based on a new Wicket module, then flattened (converted into one file) based on some tools I've written. This would be a replacement for the existing Wicket XHTML DTD and be appropriately named, e.g., -//Apache.org//DTD XHTML 1.0 Strict for Wicket 1.4//EN This DTD could of course be used to validate Wicket-produced web pages, but wouldn't be needed if the wicket: attributes were stripped from generated web pages. Ideally, Wicket would produce valid XHTML 1.0 Strict. I don't know if this is possible. Some clarification on this would be most appreciated, Thanks, Ichiro PS. on the whole I'm liking what I see with Wicket, esp. compared to Spring's increasingly complex, arcane and fragile approach to what should not be rocket science. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org Wicket only generates whatever HTML you want it to generate. The only wicket tag (or actually, attribute) you are required to use is wicket:id, which will automatically be removed from your HTML in deployment mode. So, use strict XHTML in your *.html files and strict XHTML is what will be rendered. -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
