On 1/22/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Our current Wicket release distribution consists of several zip files,
one for each project. Each zip contains all the dependencies for that
particular project, including the wicket dependencies. This means that
when you download
On 1/23/07, Filippo Diotalevi [EMAIL PROTECTED] wrote:
On 1/22/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Our current Wicket release distribution consists of several zip files,
one for each project. Each zip contains all the dependencies for that
particular project, including the wicket
fine. you dont use maven, but we do. why should we spend extra time
packaging things in a zip, blah, blah when they are easily available to you
from the maven repo?
http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3-incubating-SNAPSHOT/
Hi all,
When I re-render a Dojo widget via an ajaxRequestTarget, I have to add
some javascript to the request depending on which widget(component) has
been added to the target. This javascript should be added in order to
re-parse new DojoWidget (from the ajax response) with dojo API. This
I ran into this issue a while back and proposed an IOnLoadContributor
interface that kind of mirrors all the good work of IHeaderContributor, but
for script that is inserted anywhere below /head, such as onload, or
script blocks in the actual body.
i think he is talking about something a bit different
what you want can be accomplished by using a bit of javascript foo
http://ejohn.org/projects/flexible-javascript-events/
you can use that func to register a bunch of window.onload events that
execute once the html has been rendered. we were
You're right, he is talking about something else :) Since you can add a
Behavior to multiple components, maybe Vincent can create a Behavior to do
this. If he does this, then he can share my problem :)
So back to my problem... I need something more than window.onload, I think.
Wicket already has
i agree its not seamless and can be improved on, perhaps you should open an
rfe to have ajaxrequesttarget properly handle behaviors that implement
iheadercontributor, but for now you can use the below (off the top of my
head)
class OnLoadJavasctiptBehavior extends AbstractBehavior implements
Will do. Looks good, but I think it needs to be baked in further up the
hierarchy, so that any behavior can make its contribution without regard as
to whether it is rendered in a ajax request or page request.
thanks,
jim
On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i agree its not
Hi Igor,
Actually, I do use maven. I just have lots of bad experiences with it.
Including it screwing up my eclipse config files. I don't like it when I
have to read a whole book for something simple as building (well,
perhaps it is not so simple anymore :( ).
- do we need to supply all
I'd like us to include the src jars. It should be just an option with
maven, and I always hate it when I have to do it myself (like with
most projects unfortunately).
Eelco
On 1/23/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi Igor,
Actually, I do use maven. I just have lots of bad
well, i dont really see the difference
you can either
a) go to our website
download a zip
extract the zip
put the bin jar into your project
put the src/javadoc jar into your project
or
b)
go to our website
click the link to bin jar that points to the maven repo and save that into
your project
if you want dependencies why not download quickstart? that zip has all the
deps.
do you expect wicket-spring.zip to contain spring.jar?
-igor
On 1/23/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi Igor,
It seems like you're mixing two things: the zip-with-dependencies and
the src jars.
Currently it does. And yes,when I download a project I typically
expect it to work out of the box, no strings attached. I really hate
having to hunt down dependencies which are poorly documented. I also
hate it when projects include dependencies without the version info in
the filename (some
Yeah you can, and the fact that we upload with src jars is a good
thing. However, I don't expect every user to know where to find those
src files, and it sure is a lot easier to just unpack them in link
them to your IDE of choice directly.
Eelco
On 1/23/07, Igor Vaynberg [EMAIL PROTECTED]
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah you can, and the fact that we upload with src jars is a good
thing. However, I don't expect every user to know where to find those
src files,
neither do i, thats why we link to them from our website!
-igor
and it sure is a lot
On 1/23/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
If/when we are going to use the standard/default maven supplied
templates, then we will have the following distributions readily
available:
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html
why arent we already?
but there is no longer the pain of sf.net releases! since all our future
(save 1.2.5) will be asf where you just drop files into an ftp server. so if
we use default maven packaging it will remove that burden from you.
-igor
On 1/23/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Because I like
That is why I 'polled' the masses: to find out if anyone is attached
to our current packaging. Fortunately the @dev subscribers aren't
attached to the current packaging, so we can move to the default
assemblies.
Martijn
On 1/24/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
but there is no longer
19 matches
Mail list logo
