I kind of started the CDApp example as a more elaborate example of how
Wicket and something like Hibernate (but, that might as well be e.g.
JDOMax) can play together.
I have been thinking about rewriting the backend (admin part) of
www.burgerweeshuis.nl and either submit that as a Wicket
It'd do it more like: (using a Label or MultiLineLabel)
span id=wcn-[panel]
div class=ContainerTop
div class=ContainerRight
div class=ContainerBottom
div class=ContainerLeft
div class=ContainerTopLeft
div class=ContainerTopRight
0. I'm used to wcn, and I've no problem with it. If new users find it
easier it would be a good idea I guess.
Eelco
Jonathan Locke wrote:
one other related thing that's been bugging me is the wcn prefix is
so cryptic. it's more typing, but i almost wish it was just wicket-
so it's more
Pls don't forget to file an issue for this if you're gonna change it.
That way, it will be in the Maven generated change log automatically.
Eelco
Jonathan Locke wrote:
good point. anyone who doesn't want to break doesn't have to.
the change would just be ComponentTag:53:
public static final
Just use the Ognl backed PropertyModel for this, combined with either
your business objects (in fact any JavaBean you want) or e.g. a HashMap.
Eelco
Jonathan Carlson wrote:
I've been working on a dynamic form component (during my lunch hour so
the progress is a little slow).
I'm curious how
So, how do parse these CSS things then? Even if you could - it would be
very error prone - you would create a dependency between HTML/CSS that I
think is very hard to keep in sync.
Eelco
Gili wrote:
On Tue, 28 Dec 2004 16:10:57 -0800, Jonathan Locke wrote:
yup.
the right way of implementing
Actually, as we're in beta now, and not in alpha, architectural things
are allready pinned down for the larger part. We can have some changes,
but we should be committed to keep impact as small as possible. Now, for
1.1 (or even 2.x), drastic changes - if needed - are allowed again. So
we
can give you is that for simpler
problems, the old approach *will* yield simpler code, but that's only
on the HTML side. On the component end of things, I think things will
actually get simpler with the new approach. Things will fit together
better.
Gili
On Wed, 29 Dec 2004 13:40:46 +0100, Eelco
Ooops, I meant to send it to the list instead of to you personally. I
just did a re-post
Gili wrote:
Ok, so if I understand you correctly: you don't consider moving
from a id attribute approach to full-fledged wicket tags a major
change that would force users to have to re-learn working with
Jonathan Locke wrote:
i don't think tooling is precluded either. and designers are familiar
with existing tags. also, how easy is this XHTML stuff going to be in
dreamweaver? that's half the point of wicket is to leverage dreamweaver.
here's a crazy idea! ask wouter for an opinion! ;-)
I
I agree it's good/ not damaging to be able to pass parameters from HTML
to Java. Some things would be completely natural, like specifing the
numer a rows per page for a pagable table. It would be good to allow
designers to decide on issues like that. Just an example of the issue
being
Hmmm. I'm not convinced yet. I like it from a designer's perspective
(not having to use id=wicket-[autolink]), but really dislike it from a
programmers perspective (implicit behaviour is scary).
Gili wrote:
Jon and I would like to propose a replacement for autolinks.
Instead of users
And one more thing. Say, you've got Home.html relative to your current
package, and you've got Home.html in your webapp directory. Is see a
problem here.
Eelco
Eelco Hillenius wrote:
Hmmm. I'm not convinced yet. I like it from a designer's perspective
(not having to use id=wicket-[autolink
I am still +1 for a change that allows autolinks to work with other
packages. Like 'admin/Home.html'.
Eelco
Juergen Donnerstag wrote:
Please be a bit more specific. The current [autolink] feature is
limited in that it is only able access subpackages (see javadoc
resolveAutolink) - kind of
Yep, that's what we mean :)
Juergen Donnerstag wrote:
am still +1 for a change that allows autolinks to work with other
packages. Like 'admin/Home.html'.
you mean / instead .? Because admin.Home.html is already
supported. Though I admit it doesn't look very nice.
Juergen
Gili, thank you for explaining, but I still do not agree with you.
So we have:
/WebApp - webapplication root path
/WebApp/Home.html - Home.html that isn't registered with a
Wicket page
/WebApp/sub/OtherPage1.html - some HTML page
/WebApp/sub/Home.html - HTML page registered with a
I made up my mind about the autolink replacement proposal (which is that
instead of using a id=wicket-[autolink], all anchors would be scanned
and tested for matches with Wicket pages).
I am -1 on this. I see one theoretic advantage (not having to think
about adding the [autolink] id) and many
The thing I loath about this is that it is implicit. You have to explain
a designer that the anchors will be parsed and that, depending on what
Wicket pages there are, the anchor wil point to either a static resource
or a Wicket Page. The current situation is better as it is allways
Ok, ok. You know what? I'll just back off from this discussion, and see
where it heads. Maybe, I'll be convinced along the way, but for now: 'me
-1 for automatic anchor processing'.
Eelco
Gili wrote:
On Sat, 01 Jan 2005 22:12:06 +0100, Eelco Hillenius wrote:
The thing I loath about
With the risk of starting another thread... though it is very nice to
have these kind of resources, they are also quite inefficient to use. In
the case of images: as the image url's constantly change (via the
rendering count), the browser will never be able to mark them as cached.
It would be
Actually, on second thought, this wouldn't be hard nor dirty at all.
Just unpack resources (e.g. with path names) to the web app dir, and
keep a mapping somehow.
Problems still would be whether you have write acces or not (user's/
admin's responsibility) and whether those resources should be
. delay?
Eelco Hillenius wrote:
With the risk of starting another thread... though it is very nice to
have these kind of resources, they are also quite inefficient to use.
In the case of images: as the image url's constantly change (via the
rendering count), the browser will never be able to mark
Yep, that's it.
Gili wrote:
I assume this means this part of the HTML is purely for
previewability purposes and during runtime it gets completely stripped
out, including its body/children-tags, right?
Gili
---
The SF.Net email is
Juergen is still working on that one.
Eelco
Gili wrote:
Hi,
I'm taking a look at the new example code that's supposed to
use the new namespace and autolink approaches. It seems to still use:
h2a id=wicket-[autolink] href=DisplaytagIndex.htmlExample/a
gt; Standard, smart linking of column
I tried it some time ago, and did not find leaks. I would be a good idea
for more people to do some serious profiling.
Anti-patterns would be using too many internal classes (I just found
out); you'll end up with spaghetti code. And - though not an
anti-pattern - be carefull about your
will be harder.
Eelco
Eelco Hillenius wrote:
I tried it some time ago, and did not find leaks. I would be a good
idea for more people to do some serious profiling.
Anti-patterns would be using too many internal classes (I just found
out); you'll end up with spaghetti code. And - though
I made one. But Johan made a better one.
Johan, is your tab-thingy re-usable yet? Generic enough to e.g. put in
contrib?
Eelco
Jonathan Carlson wrote:
Has anyone started a TabbedPanel yet?
Just Curious. I didn't see one but I'll need one eventually. If I
write it myself does anyone have
Yep. That's the nicest way to do it.
You probably want to use this setting (false by default):
settings.setPropertyModelDefaultApplyFormatting(true);
as then the converting works both ways.
If you take a look at the forminput example (CVS HEAD), you'll see:
TextField dateInput = new
Ooops: 'Because I added a type converter, ...' should have been:
'Because I added a TypeValidator, ...'.
Eelco
Eelco Hillenius wrote:
Yep. That's the nicest way to do it.
You probably want to use this setting (false by default):
settings.setPropertyModelDefaultApplyFormatting(true
button
would then also just have a navigation action.
Eelco
Eelco Hillenius wrote:
It's much better to use a seperate button, like currently in CDAPP.
Java:
add(new OnClickLink(cancelButton)
{
public void linkClicked() {
getRequestCycle
Johan Compagner wrote:
yes this is also a thing that i don't like very much currently.
With links you can add a link and then implement linkClicked()
It would be nice that buttons also work this way..
Or just use the OnClickLink instead of Link. Works the same, with the
difference that
'the onSubmit is
handled in subclasses.'.
Martijn
Eelco Hillenius wrote:
Actually, things like:
getRequestCycle().getRequest().getParameter(save) != null to signal
whether a submit or cancel was pressed, typically comes from the
non-component based approach, where all form submits would enter
you propose?) extend form with not only a
formSubmitted, but also with e.g. a formCancelled method, and a cancel
button component that works with these. Personally, I am not
enthousiastic about this, as it keeps people thinking in a non component
based way.
Eelco
Martijn
Eelco Hillenius wrote
is it component based? If this is
non-component based, then the 'onSubmit' should be removed as well,
because one can use a submit Button with an onClick event for this
purpose.
Martijn
Eelco Hillenius wrote:
Martijn Dashorst wrote:
You say two things:
- use buttons and their on click event in Swing
Good thing about setVisible is that it won't give you back-button
troubles, as all components - be them visible or not - will be
reachable, whereas when you replace a panel, the replaced panel will not
be reachable.
Eelco
Jonathan Carlson wrote:
I think I like your setVisible(boolean) option
I have not used the component yet, so I guess it's a bit raw ;) It (or
commons-upload) certainly can have multiple uploads, but currently the
interfacing with normal Wicket forms does not work properly.
We'll get on the job of properly integrating it; I'll file an issue for it.
Cheers,
Eelco
Furthermore:
- you can access the currently used instance of IConverter by calling
getConverter() on any component;
- an instance of IConverterFactory creates the instance of IConverter to
be used by the current session. There is a usefull default, but you can
override this by overriding
Hi,
The preffered way now is to extend CustomValidator and call one of the
error(... methods of AbstractValidator when a validation error occurs.
This could be simple like in RequiredValidator
public void onValidate(String value)
{
// Check value
if (Strings.isEmpty(value))
Well, this part:
Caused by: java.util.MissingResourceException: Unable to find resource:
datenForm.text1.DatumsValidator
at wicket.Localizer.getString(Localizer.java:110)
at wicket.Localizer.getString(Localizer.java:212)
shows that Wicket looks for resource with resource key
Stefan Lindner wrote:
Just one step forward to the solution:
If you use a CustomValidator and bind it to an TextField (and perhaps
other input fields) you MUST have a resource file with the name schemea
name of your class associated with the form element.properties.
Actually, it is like name of
Yeah, the docs are seriously lacking. To at least make up for that a
bit, there are quite a few examples.
Specific reusable components with markup (the HTML part) are the Panel
and Border components. Please take a look at them at the examples.
Eelco
Stefan Lindner wrote:
Thank you all for your
There several ways of doing this. E.g. (came up with a quick google):
http://www.quirksmode.org/css/centering.html
Eelco
Gili wrote:
I've got the border to work but now I want to have it center in
the middle of the page. I am not familiar with CSS in this domain: how
does one center
Yep. I see advantages of implementing AJAX as well. See my blog post at:
http://www.jroller.com/page/Eelco12/20050321 (I hope to have posts on
Wicket on a more regular basis now, same goes for Martijn:
http://www.jroller.com/page/dashorst/ and Jonathan:
Hi Antonio,
I put up an article on our Wiki on this:
http://wicket.sourceforge.net/wiki/doku.php?id=user:listview_with_checkboxes_in_a_form
Regards,
Eelco
Antonio Casula wrote:
I saw the example displaytag/ExampleCheckbox and I
have a question: How is possible to get the checkboxes
and input
You're not extending nor touching the business object, as you're
wrapping it (i.e. putting a class 'around' it).
class MyWrapper
{
private MyBusinessClass;
private Boolean selected;
}
If you wrap an object, you don't touch it in any way; you can allways do
this. The only thing to keep in
and render phase.
Also, I just found out that the border component is broken. Probably
something small, but the border component can't be used at all in head now.
Cheers,
Eelco
Juergen Donnerstag wrote:
I'll try it
Juergen
On Sat, 26 Mar 2005 07:24:52 +0100, Eelco Hillenius
[EMAIL PROTECTED] wrote
A page is instantiated when:
- you clicked a bookmarkable link (e.g.
http://localhost:8080/wicket-examples/navomatic?bookmarkablePage=wicket.examples.navomatic.Page2);
- you went to the Home page;
- you instantiated it yourself or had a page factory instantiate it,
e.g. by using a PageLink or
You're not? We do. Though the web application part is just a part of the
whole, we're using Wicket for our 7 man year + project right now.
The fact that we don't have javascript support etc. build in yet,
doesn't mean it is not useable. You can do Javascript, AJAX, whatever
right now if you
First, did you used packaged images in your JSP? Guess not. The
resources had an issue. But that's fixed - again.
And what gives you any idea about what we're using in our applications?
The app I have been working on in a team of three pretty much uses all
of the HTML components there are,
. How can I achieve this?
Again, sorry for asking noob questions.
thanks,
Kristof
Eelco Hillenius wrote:
A page is instantiated when:
- you clicked a bookmarkable link (e.g.
http://localhost:8080/wicket-examples/navomatic?bookmarkablePage=wicket.examples.navomatic.Page2);
- you went to the Home
And note Chris' message earlier this week: String.replaceAll seems to
eat up a lot of resources, so instead of using a regex here, we should
use a cheaper replace.
Eelco
Jonathan Locke wrote:
that's a nice fix. but i want to test my fix too because the problem
you point out below was causing
One thing I can imagine is a form with a panel attached, that you feed a
java bean. Based on the properties of that java bean (using
introspection), you could add form fields to the form.
This is quite easy to accomplish for simple introspection, though if you
really want to do a good job,
We could also consider making this a contrib component, or maybe even
just a Wiki section. It's pretty specific, unless it is really good
(full fledged java bean descriptor stuff).
A simple version is quite easy to implement. Might do it this weekend,
or - if Ari wants to give it a shot, we
actually have done allready (though not by
introspection) for our project here. Works really well.
Eelco
Jonathan Locke wrote:
Eelco Hillenius wrote:
We could also consider making this a contrib component, or maybe even
just a Wiki section. It's pretty specific, unless it is really good
(full
The other case I was originally posting about (ie. having full
screen design in html) is pretty much standard wicket use, only
with small optimization related to coding work (ie. instantiate
suitable wicket components like TextField, DropDownChoice,
RadioChoice based on bean's
like form-name.property-name in a resource bundle.
This would work very well. Our old system has this done just like
this.
Ari S.
Jonathan Locke wrote:
Eelco Hillenius wrote:
We could also consider making this a contrib component, or maybe
even just a Wiki section. It's pretty
Nope, though Martijn *is* very bussy writing articles. Volunteer?
Eelco
Jonathan (Carlson)
P.S. Who's writing the Wicket book? Anyone yet? :-)
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of
I saw this question (where did cdapp go) on one of the lists recently.
Cdapp was moved to wicket-stuff (http://wicket-stuff.sourceforge.net/)
as part of the examples subproject. Unfortunately, I haven't had the
time to make a decent distrubution, so you won't find it in the file
section. The
I'm not sure I understand what you're looking for. Do you mean HTML
table? In that case you can just put the tree in the td (like td
span wicket:id=someTree / /td).
Could you tell us in more detail what you want?
Eelco
Stephen Knight wrote:
Hello,
Has anyone created a TreeTable component? I
I just worked on the manual a bit more. Can't believe how much time it
costs to just put down a couple of sentences, but well...
http://wicket.sourceforge.net/wiki/doku.php?id=newuserguide
Eelco
Jonathan Carlson wrote:
Thanks, I hadn't thought of using the Wiki for this.
I think that's Wicket quickstart, which is now in Wicket Stuff
(http://wicket-stuff.sourceforge.net)
Eelco
Per Ejeklint wrote:
Hi all, is there an empty Eclipse-project to use as a start for new
Wicket-applications floating around somewhere? I think I read about it
somewhere but can't find
Yep. Who'll bug Matt though, as I think he is the one who decides which
frameworks are supported...
Especially the sub project 'Equinox' would be a breeze to develop
(basically, it's a simple CRUD app with a pageable list).
Eelco
Stephen Knight wrote:
It would be really cool if there was a
there? Anything you could recommend? Currently
I like the looks of Liferay, especially since they now support the
'light weight' (non-EJB) model. However, GridSphere, Gluecode,
Stringbeans and Jetspeed are alternatives...
Regards,
Eelco
Eelco Hillenius wrote:
Nope, we don't support that at this time
It would be great if you could send a 'get started in NetBeans' for
dummies description. We'll put that on the site/ in our docs (and I'll
give it a try as well :)).
I had some problems getting the projects from sourceforge using SSH. I
found this:
where to put it, etc.)
4. Click Finish.
That's it.
If anything's unclear, please let me know.
Thanks,
Geertjan
PS: Whose name is Dutcher: yours or mine? :-)
Eelco Hillenius wrote:
It would be great if you could send a 'get started in NetBeans' for
dummies description. We'll put that on the site
That's a smart trick they're doing. I'm not whether it is a good idea
for Wicket however. I think we're not doing that bad, having just 3
needed dependencies (ognl, concurrent and commons-logging... can someone
confirm we don't need dom4j?). The advantage of not packaging the jars
is that it
That certainly would be nice functionality.
Alternatives (for now):
- use a filter (I thought that was mentioned in an earlier discussion as
well);
- put you webapplication in a frameset, so that the user doesn't see the
urls.
Eelco
Juergen Donnerstag wrote:
no, not yet, but an RFE has already
There are generally two ways of doing this (I think):
1. Page oriented. Create a page for each step, and record your status by
either passing it to the step pages as you construct them.
2. Panel oriented, using:
a. 'replace'. This way you have one panel (e.g. 'mywizPanel'), where
your step
Maybe we should write out a competition: who builds the best high-level
reusable wizzard component :)
Eelco
Martijn Dashorst wrote:
I have put this on the wiki
(http://wicket.sourceforge.net/wiki/doku.php?id=user:building_wizard_functionality),
as this is a recurring question...
Martijn
Eelco
I don't know what your problem is; I need more code.
Anyway, here are a few hints for working with converters in general:
- be sure conversion works two ways. Generally you have to have a
converter for get- and one for setObject;
- conversion is only automatic when you use the PropertyModels
It was our idea to have at least a part that can be edited by devs only,
and to have a 'public edit' part. I'm not sure what happened with the
public part though.
Hmmm... maybe we should make it more open?
Eelco
Jonathan Carlson wrote:
I'm curious why a Sourceforge e-mail address is required to
from that, what else could be going
wrong?
Gili
Eelco Hillenius wrote:
I don't know what your problem is; I need more code.
Anyway, here are a few hints for working with converters in general:
- be sure conversion works two ways. Generally you have to have a
converter for get- and one
Let's extend the form example in wicket-examples with a custom
converter. I think your InternetAddressConverter could make a nice
example, right?
Eelco
Gili wrote:
I'd like to discuss this issue online with one of you, preferrably
over MSN, AOL, or Yahoo messenger.
I am using
I'm not that well versed with Wiki's, but what does 'open' namespace
mean? And how can we get it back on the home page?
Eelco
Anything under the 'open' namespace can be edited openly, although
it looks as if there's no link to it's top from the home page any
more!
:
Sounds good to me. I'm more than happy to contribute it.
Gili
Eelco Hillenius wrote:
Let's extend the form example in wicket-examples with a custom
converter. I think your InternetAddressConverter could make a nice
example, right?
Eelco
Gili wrote:
I'd like to discuss this issue online
you are able to reproduce the same problem on your end.
Thanks,
Gili
Eelco Hillenius wrote:
Ah, I just found out that InternetAddress is part of the java mail
package. I'll use URL instead; the trick is still the same.
Btw, you're a NetBeans user if I remember right... Is the build.xml
we put
Here's my first remark: instead of:
catch (AddressException e)
{
throw new IllegalArgumentException(e);
}
do:
catch (AddressException e)
{
throw newConversionException(' + value + ' is not a valid
URL, value, null);
}
or anything else that throws a
URL instead of InternetAddress (just
for the test)?
Eelco
Eelco Hillenius wrote:
Here's my first remark: instead of:
catch (AddressException e)
{
throw new IllegalArgumentException(e);
}
do:
catch (AddressException e)
{
throw newConversionException(' + value
URL by InternetAddress.
Gili
Eelco Hillenius wrote:
I just implemented URL converter here, and it works without
problems... I still don't know what your problem is now.
Anyway, I'll make the example a bit nicer and commit it later. Could
you see whether your problem still exists in HEAD
Not sure yet if it is your bug as well, but at least we're on to something.
Eelco
Gili wrote:
Good catch! I'll wait on the bugfix, hopefully it'll solve the
problem.
Gili
Eelco Hillenius wrote:
Yeah, found a problem when I stepped all the way through...
In CompoundPropertyModel:
protected
,
this is a design misfeature.
the easy workaround is to use the bound compound model, which lets you
specify propertyType
best,
jon
Eelco Hillenius wrote:
Not sure yet if it is your bug as well, but at least we're on to
something.
Eelco
Gili wrote:
Good catch! I'll wait on the bugfix
I'd go for either the option that Jonathan suggested (providing your own
Panel for a node), or - just as easy - create a special Page, that has
the redirect in it:
html
head
meta wicket:id=redirect http-equiv=refresh content=0; url=app
/head
/html
On this page, you add:
That's not a bug.
Caused by: java.util.MissingResourceException: Unable to find resource:
form.email.TypeValidator
at wicket.Localizer.getString(Localizer.java:147)
means Wicket can't find resource with key 'form.email.TypeValidator'. By
default Wicket throws an exception when it can't find
I'm +1 for allways validating the form. If you (the user) want to get
around that, you can allways just add a Link instead of a button that
works with a form.
Eelco
---
SF email is sponsored by - The IT Product Guide
Read honest candid
Eelco Hillenius wrote:
I'd go for either the option that Jonathan suggested (providing your
own Panel for a node), or - just as easy - create a special Page, that
has the redirect in it:
html
head
meta wicket:id=redirect http-equiv=refresh content=0; url=app
/head
/html
On this page, you add
object and not a string.
so instead it might be: redirectTo(new RedirectPage(www.google.com))
Eelco Hillenius wrote:
Actually, I think it would make a nice API addition. We could have a
'redirect page' packaged with Wicket (you'd never have to use it
directly), and you call redirectTo
You can't do that with the current request cycle. However, you could use
the same trick as in the 'redirect to outside wicket in tree'
discussion, but instead of
meta wicket:id=redirect http-equiv=refresh content=0; url=app
you could do
meta wicket:id=redirect http-equiv=refresh content=5;
Hmmm. I guess using a page object is proper OO.
Eelco Hillenius wrote:
Well, I don't know what I like better. I like the string argument
method for that users don't have to know about a RedirectPage.
Eelco
Jonathan Locke wrote:
uh, i mean setResponsePage(new RedirectPage(...))
Jonathan Locke
Just do what we were discussing: include a component (e.g. a
WebMarkupContainer) and attach that to the meta tag, and use the visible
property (set it to true when you want the meta tag to render, and thus
have the redirection happen).
Kind of copy paste of the RedirectPage.
Eelco
Gili wrote:
() wouldn't get invoked?
Where am I supposed to setVisible(false)?
Thanks,
Gili
Gili wrote:
Ok, sounds good. Thanks! :)
Gili
Eelco Hillenius wrote:
Just do what we were discussing: include a component (e.g. a
WebMarkupContainer) and attach that to the meta tag, and use the
visible property (set
You can do that easier I think. Just have your redirect header in there
all the time, but have the visible property false. In your submit
handler, you set the visible property true, and the redirect will
happen. If you want to be sure the flag is only set false when you are
in your submit
Agreed, I followed up myself :)
Jonathan Locke wrote:
the thing i don't like about it is that it gets users started thinking
about urls. if they see this method, their next question may be
something inappropriate, like how do i get the url to page x so i can
redirect to it...
Eelco Hillenius
and it would be useful to be able to
specify a non-zero value.
Gili
Juergen Donnerstag wrote:
I'll do it tonight.
Juergen
On 4/22/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
Erhm... could you do that when you have access to CVS later on? I am
not
very familiar with that part of Wicket, and I
already exists,
but we could supply one too
Eelco Hillenius wrote:
Ah, ok. Good point; didn't think of that. However, I don't think it
is something we should support out of the box. It is very easy to
implement yourself. Core doesn't have to support everything you can
ever think of, right
- feel free to edit as desired.
On 4/20/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
I'm not that well versed with Wiki's, but what does 'open' namespace
mean? And how can we get it back on the home page?
Eelco
Anything under the 'open' namespace can be edited openly, although
it looks
The cdapp example (you can find it in
http://wicket-stuff.sourceforge.net , project wicket-contrib-examples),
reuses the page to redirect to. And that works quite good, though there
is one issue to solve (actually I forgot about that one, thanks for
reminding me): when you reuse such a page,
Yeah. Ooops. That's the delete button... thought I fixed that one!
Anyway, it's not the only bug... when you add a new item, the list isn't
refreshed directly.
I'll fix it now. Thanks,
Eelco
Jonathan Carlson wrote:
I just ran across Martijn's blog about the new online cdapp example. As
I
But it is a trash can. And it's my favorite! What would be a better
idea, is to have an ok/cancel javascript warning. Had that in mind
anyway, but now the example is put live, I guess I have to make it a
priority.
Eelco
Jonathan Carlson wrote:
Maybe you could change the icon to either a trash
Strange, it works for me too (I added your name as a cd)... What browser
do you use? And do you see your name (, right?) in the list of
cd's (that cd has value '1' in the 'year' field)?
Eelco
wrote:
So many thanks. I add an cd entry at contrib-example
You either choose to have many packages or a lot of classes in one
package. Kind of the same choice you have with your file system... do
you want to put everything on c:/ or /home/ , or do you want directories
like c:/java, c:/Program Files, etc. We - and that is very usual in Java
Land -
1 - 100 of 3028 matches
Mail list logo
