i'm starting to think this is too confusing. i like just wicket:link
and app setting.
Juergen Donnerstag wrote:
On Sat, 01 Jan 2005 17:18:50 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote:
one further idea...
if we let people put a tag around any amount of
markup, it could enable "transpare
On Sat, 01 Jan 2005 17:18:50 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
> one further idea...
>
> if we let people put a tag around any amount of
> markup, it could enable "transparent autolinking" for that region (while
> still supporting for what we might informally call
> "explicit a
Juergen Donnerstag wrote:
Eelco,
not sure my informations will really matter (could be I lost track of the mails)
1) you remember the appfuse resources I send you? The menu component
is a kind of tree and the images are defined in the css file and url
refers to a static resource outside my wicket.
Not tested yet. I just did a Label like example derived from HtmlComponent.
Juergen
On Sat, 01 Jan 2005 17:42:04 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
> you rock, juergen!
>
> is wicket:component going to work for borders and panels and everything?
> how did you resolve the constr
Eelco,
not sure my informations will really matter (could be I lost track of the mails)
1) you remember the appfuse resources I send you? The menu component
is a kind of tree and the images are defined in the css file and url
refers to a static resource outside my wicket. I've checked it with
HT
i think i agree. was just throwing that out there...
Gili wrote:
On Sat, 01 Jan 2005 17:18:50 -0800, Jonathan Locke wrote:
one further idea...
if we let people put a tag around any amount of
markup, it could enable "transparent autolinking" for that region (while
still supporting for what w
On Sat, 01 Jan 2005 17:18:50 -0800, Jonathan Locke wrote:
>one further idea...
>
>if we let people put a tag around any amount of
>markup, it could enable "transparent autolinking" for that region (while
>still supporting for what we might informally call
>"explicit autolinking"). kindof lin
yes, at least. if there's an easy fix (like changing the URL encoding
for images as i just wondered about) we should do it sooner.
Eelco Hillenius wrote:
Sure, not that important right know. Good to be aware of though. We
should file it as a feature request for 1.1 IMO.
Eelco
Jonathan Locke wr
either that or map the resources to a constant url maintained by wicket
(such as blahblah/images/wicket-1.jpg)
or maybe just omit the rendering count from image urls and change the
code so it doesn't check rendering counts on images (if necessary)
seems like that's really the core problem, r
Sure, not that important right know. Good to be aware of though. We
should file it as a feature request for 1.1 IMO.
Eelco
Jonathan Locke wrote:
sounds ugly. i bet we want to fix this. 1.0 or 1.1 though?
i just want to get everything wrapped up. wicket will /work/ without
this perf tweak. de
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 cl
sounds ugly. i bet we want to fix this. 1.0 or 1.1 though?
i just want to get everything wrapped up. wicket will /work/ without
this perf tweak. 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 qui
you rock, juergen!
is wicket:component going to work for borders and panels and everything?
how did you resolve the constructor problem?
Juergen Donnerstag wrote:
On Sat, 01 Jan 2005 17:29:56 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote:
does your checkin remove [] syntax?
yes it does. I
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 n
On Sat, 01 Jan 2005 17:29:56 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
> does your checkin remove [] syntax?
yes it does. I tried to provide an exception which tells the user to
use the wicket-tag instead. Please see MarkupParser for that.
>
> it sounds like we should remove [autolink]
does your checkin remove [] syntax?
it sounds like we should remove [autolink] and introduce
for the same behavior.
i would assume such a tag would have to immediately surround the guy.
Juergen Donnerstag wrote:
That sounds like a reasonable compromise for me. I understand Eelco
and know many p
That sounds like a reasonable compromise for me. I understand Eelco
and know many people who think alike. But I'd also like to gain some
experience (if it is really that intuitive and not causing any
additional trouble) with the automatic feature
Juergen
-
+1
Eelco
Jonathan Locke wrote:
i have an idea to resolve this which might work for everyone. we
could introduce for explicitly declaring autolinks ([]
still goes away, thank goodness). then we could make an app setting
setAutomaticLinking(boolean) to allow people to turn on the "implicit"
be
one further idea...
if we let people put a tag around any amount of
markup, it could enable "transparent autolinking" for that region (while
still supporting for what we might informally call
"explicit autolinking"). kindof link having the setAutomaticLinking
on/off switch in the markup...
i have an idea to resolve this which might work for everyone. we could
introduce for explicitly declaring autolinks ([] still
goes away, thank goodness). then we could make an app setting
setAutomaticLinking(boolean) to allow people to turn on the "implicit"
behavior. the default would be o
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 this is th
On Sat, 01 Jan 2005 22:12:06 +0100, Eelco Hillenius wrote:
>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 Pag
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
immediately
the thing i love about this is that designers would not have to think
about links. they could just leverage dreamweavers extensive linking
functionality directly.
Jonathan Locke wrote:
if we ignore the conflicts between static pages and wicket pages
(which i think users will resolve in an ad-h
On Sat, 01 Jan 2005 12:45:53 -0800, Jonathan Locke wrote:
>i was initially in agreement with your idea to make autolink work
>exactly as before but automatically. i still tend to think this, but
>i'm trying to understand problems people are having with that since they
>may be right.
F
if we ignore the conflicts between static pages and wicket pages (which
i think users will resolve in an ad-hoc way, possibly using folders, for
example) and the minimal performance impact, is there anything wrong
with the proposal to make autolinks work exactly as-is automatically?
Jonathan Lo
i was initially in agreement with your idea to make autolink work
exactly as before but automatically. i still tend to think this, but
i'm trying to understand problems people are having with that since they
may be right.
Gili wrote:
On Sat, 01 Jan 2005 12:35:54 -0800, Jonathan Locke wrote:
i don't have an opinion yet. i'm just trying to understand the problem.
Gili wrote:
On Sat, 01 Jan 2005 12:35:54 -0800, Jonathan Locke wrote:
i understand the "problem". i just don't think it's worth fixing. in
fact, "fixing" it is kindof against wicket philosophy and tends to take
a view o
yes. we'd provide some syntax there using xhtml i imagine. maybe
something as straightforward as:
foo
but that begs the question "why have this syntax at all when it could be
automatic"...
i'm still on the fence here.
Gili wrote:
Even if we keep the old autolink approach, how would
On Sat, 01 Jan 2005 12:35:54 -0800, Jonathan Locke wrote:
>i understand the "problem". i just don't think it's worth fixing. in
>fact, "fixing" it is kindof against wicket philosophy and tends to take
>a view of "wicket is the world", which it will never be. the wicket
>philosophy is to let
i believe sourcepath is around for doing dynamic updates for development
speed (so you can change a page and just hit refresh without building).
it might also have some diagnostic uses now or in the future.
Johan Compagner wrote:
they shoud not.
Of course we can have static html files and html
Even if we keep the old autolink approach, how would you refer
to it now? We no longer support IDs with brackets in them.
Gili
On Sat, 01 Jan 2005 21:33:13 +0100, Eelco Hillenius wrote:
>I made up my mind about the autolink replacement proposal (which is that
>instead of using http://w
i'm not sure i agree that the performance impact matters. and the
current method is arguable at least as error prone. also, you omitted
the advantage of transparency. the transparency of links just working
the way a designer would expect is pretty huge.
i think i'm still 0 (undecided) on this
i understand the "problem". i just don't think it's worth fixing. in
fact, "fixing" it is kindof against wicket philosophy and tends to take
a view of "wicket is the world", which it will never be. the wicket
philosophy is to let things do what they do well and not try to change
them; to del
they shoud not.
Of course we can have static html files and html files belonging to a
wicket component.
These 2 are 2 totally different things ..
Why is there a sourcepath? Is there a real need to be able to seperate
the 2 in a different source path?
If you want to be able to change the html fil
On Sat, 01 Jan 2005 12:29:09 -0800, Jonathan Locke wrote:
>i guess one of the reasons i haven't been following this conversation is
>because
>i don't really understand the need for it. the existing autolink
>functionality works
>really well and allows both dynamic wicket html and static html in
I made up my mind about the autolink replacement proposal (which is that
instead of using Regards,
Eelco
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun
i don't really see this as a problem. we search the wicket class area
first and then do nothing if
it's static. the framework user can figure this in whatever ad-hoc way
they want. it's not like
they will be all that confused by the behavior...
Gili wrote:
On Sat, 01 Jan 2005 12:22:00 -0800,
i guess one of the reasons i haven't been following this conversation is
because
i don't really understand the need for it. the existing autolink
functionality works
really well and allows both dynamic wicket html and static html in the
way familiar
to users of app containers. all that's neede
On Sat, 01 Jan 2005 12:22:00 -0800, Jonathan Locke wrote:
>Gili wrote:
>
>> That's why I've stated before I think we should disallow the
>>ability to store HTML files both under /WebApp/ and
>>/WebApp/WEB-INF/classes/ -- force one or the other. Otherwise it could
>>lead to confusing behavior
Gili wrote:
That's why I've stated before I think we should disallow the
ability to store HTML files both under /WebApp/ and
/WebApp/WEB-INF/classes/ -- force one or the other. Otherwise it could
lead to confusing behavior for the user. If we force all HTML files
under a single root path we guara
That's why I've stated before I think we should disallow the
ability to store HTML files both under /WebApp/ and
/WebApp/WEB-INF/classes/ -- force one or the other. Otherwise it could
lead to confusing behavior for the user. If we force all HTML files
under a single root path we guarantee
normally (if you don't set a sourcepath in the ApplicationSettings) the
html must be beside the class.
So in the package.
But a href to something in a page can contain this: Xxxx.html
That thing could be a normal (no wicket component html file) that is in
the webroot
Or it could be a html file t
On Sat, 1 Jan 2005 11:24:23 +0100, Juergen Donnerstag wrote:
>> 1) We unify the resource path. You must place all your files in
>> /WebApp/ or /WebApp/WEB-INF/classes/ but not both.
>
>I'd like to skip that feature only for something really important.
What do you mean?
>> 2) Contrary to
Happy new year to all fo you
>
> 1) We unify the resource path. You must place all your files in
> /WebApp/ or /WebApp/WEB-INF/classes/ but not both.
I'd like to skip that feature only for something really important.
> 2) Contrary to my previous email, you can refer outside the WebApp.
> Referi
Here's a revision that better addresses Eelco and Juergen's
concerns.
1) We unify the resource path. You must place all your files in
/WebApp/ or /WebApp/WEB-INF/classes/ but not both.
2) Contrary to my previous email, you can refer outside the WebApp.
Refering to "/" refers to the root p
My initial thought is that you should enforce *one* path
hierarchy. That is, all HTML files must either go in
/WebApp/WEB-INF/classes/* or in /* but not both. This would solve your
inability to differentiate between /Home.html that might lie in two
places:
/WebApp/WEB-INF/classes/Home.htm
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 Wicke
On Thu, 30 Dec 2004 23:23:57 +0100, Eelco Hillenius wrote:
>Silly? Why is that? 'Unless you explicitly convert them'? The old
>behaviour is to add a link with broken links? I add these links just as I add components like:
>When I say I like it from a designer's perspective, I mean that it
>*cou
On Thu, 30 Dec 2004 20:06:13 +0100, Juergen Donnerstag wrote:
>>
>> > How are we going to support absolute package-path?
>>
>> Users can specify the Webapp base path, like you suggested.
>
>You certainly know this is a problem JSP world and the reason why
>almost all frameworks have some
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).
Eelco, this is silly. With the old behavior, unless you
explicitly convert them to autolinks
>
> > How are we going to support absolute package-path?
>
> Users can specify the Webapp base path, like you suggested.
You certainly know this is a problem JSP world and the reason why
almost all frameworks have something like $contextPath variables.
Something, I definitly don't want.
I'm going to try to respond to everyone's concerns here. First,
let me say that the autolink replacement is meant to do what the old
autolink did and not more. It seems to me that some of the concerns you
have here are asking for more than the original implementation did.
Furthermore, auto
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
--
> 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
---
The SF.Net ema
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 relativ
- How are we going to support absolute package-path?
we should.
- I recall Jon talking about an alias map (Admin.html =>
administration/Home.html) to be set through AppSettings
not preferred by me.
- The currenlty implementation works with admin.Home.html. I propose
the new one will ONLY wo
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]"),
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 e
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 relative paths.
- How are we going to support absolute package-path?
- I recall Jon talking about an alias map (Admin.html =>
administration/H
So we are going to test every to see if it points to a wicket page
(you try to get a page constructor for the given href i take)
If this doesn't take to much resources (memory and cpu) then this looks
good to me.
johan
Gili wrote:
Jon and I would like to propose a replacement for autolin
Jon and I would like to propose a replacement for autolinks.
Instead of users explicitly declaring [autolink], we'd automatically
convert tags to autolinks and treat their query string as page
parameters. This new approach is capable of replacing all preexisting
autolink functionality.
P
62 matches
Mail list logo
