the idea below is starting to seem fairly elegant to me. thoughts everyone?
Jonathan Locke wrote:
refinements:
by "we are still going to need them for various purposes", i mean stuff like [border] and [body] which are never going to go away through generality because they are so incredibly special purpose.
also, if you want to instantiate a class in the same package, you could omit the package name. if we really wanted to give people the ability to abbreviate, we could let them set up mappings in application settings to allow them to import components with abbreviated names. for example:
getSettings().addComponent("roundBorder", com.mystuff.RoundedBorder);
then you could use roundBorder instead of the class throughout your app.
doesn't this give you the kind of extensibility and abbreviation you want?
Jonathan Locke wrote:
yeah, except the whole point of autolink was to reduce work and verbosity...
links are the most common thing on a site and so i created [autolink] because that
special magic could make them dirt simple, abbreviated and painless. getting rid
of that magic for the sake of generality alone seems like it decreases usability for
no good reason. i think the exception is worth it. the fact that NOBODY can make
up special keys is not such a huge deal to me. we're still going to need them for
various purposes and i'd like to essentially reserve that whole namespace for internal
use only by not allowing users to define them at all.
in this scheme, to instantiate a user class with no args, you could use the current command syntax:
<span id = "wicket-[new:classname]"/>
to extend this with the xhtml args thing, you'd say:
<span id = "wicket-[new:classname]"><wicket param = "12"></span>
or you could abbreviate another way with just just
<wicket new = "classname" param = "12"/>
seems pretty straightforward to me. maybe another way of saying:
<a id = "wicket-[autolink]" href = "foo.html">
would be
<a id = "wicket-link-0" href = "foo.html"><wicket new = "wicket.markup.html.link.PageLink" autolink = "true">
but who would want to say that? ;-)
Gili wrote:
On Wed, 29 Dec 2004 10:12:23 -0800, Jonathan Locke wrote:
i just said we'd leave autolink alone (wicket-[autolink]). that syntax would identify and/or instantiate a component parameterized by the optional xhtml args.
and maybe custom components don't /have/ to have the id bit at all... they can optionally just have the xhtml specifying class and params (if they don't attach to some specific tag)
There's still the problem that I pointed out that [autolink] is a "magic" key that somehow identifies the Wicket component type. I don't like that. It seems to me like:
1) People will want to define their own keys for identifying their components without an ID 2) It is somehow unintuitive to me.
I would rather one *had* to bind against a specific Wicket component from the HTML end and "autolink" was just a normal key like any other.
Gili
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
