Re: Feature Idea / Request
Hi,
I do not follow current development on 2.0, but it seems to me, that
link with label is only 'specific' case of 'generic' link, so extending
Link class and introducing LinkText class (or whatever name you choose)
should make the trick.
Something like:
public class LinkText extends Link {
final Label label;
public LinkText(String name) {
add(label = new Label());
}
and then you can have your methods to access label ...
Probably you would have to change the check if markup for label exists as
well, but as it is usually text only, it should not be big deal ...
Or did I miss something ?
saki
> i am against it because i feel it perverts the api and the nature of
> component orientation.
>
> if you think of it as a desktop link component then yeah text makes sense
> there as a property because you cannot put anything else into a link -
> because most desktop link components dont let you - but in wicket you can.
>
> just start a vote because obviously there is no middle ground here.
>
> -Igor
>
>
> On 10/26/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>>
>> yuk!
>> that doesn't help at all
>> why ohh why would you trade this:
>>
>> new Link(this,"link").add(new Label())
>> for
>> new Link(this,"link").add(new BodyModifier())
>>
>> thats doesn't solve anything.
>>
>> Last thing i just say about this. Why do we constantly get this
>> question??
>> Because people see link text as the link text. I had exactly that same
>> reaction from day 1
>> I know jan blok also had that. I find it always so ugly that you have to
>> add
>> a span inside a link and then add a label to the link component
>> So i am +1 for adding getLabel() (and maybe setLabel()) to Link
>> i am really -1 for introducing a completely seperate hierachy. Then just
>> do
>> nothing and let it be like it is now and let users implement there own
>> when
>> needed.
>>
>> I still don't get it why you guys are so against it it doesn't get in
>> your
>> way at all. It is just a very nice and handy thing to have for all the
>> people that think
>> like me that the text of a link is the property of that link.
>> And no you also have a lot of text that is dynamic and not i18n like
>> Listviews with data where an entry is directly a link. (that is used all
>> over the place in my solutions)
>>
>> johan
>>
>>
>>
>> On 10/26/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>> >
>> > I was already thinking along the line Igor mentioned:
>> >
>> > I'm thinking of a BodyModifier. A BodyModifier is added to a
>> > component, and alters the body in a similar fashion as an attribute
>> > modifier:
>> >
>> > dummy
>> >
>> > new Link(this, "link").add(new IBodyModifier() {
>> > public CharSequence onComponentBody(CharSequence body) {
>> > return " + body + "";
>> > }
>> > });
>> >
>> > or
>> >
>> > new Link(this, "link").add(new IBodyModifier() {
>> > public CharSequence onComponentBody(CharSequence body) {
>> > return "My new contents";
>> > }
>> > });
>> >
>> > That would be more scalable in terms of api then slapping getLabel()
>> > at random to components where the getLabel() has different semantics
>> > depending on the component.
>> >
>> > However I think this one will be misused by beginners of the framework
>> > to things they could do in a more component oriented way.
>> >
>> > Martijn
>> >
>> > On 10/26/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>> > > On 10/26/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > This is so crap
>> > >
>> > >
>> > > those are my thoughts exactly on adding that property :)
>> > >
>> > >
>> > > People don't see links as containers.. they could be but for 99% of
>> the
>> > > > cases they are not used like this
>> > >
>> > >
>> > > well, they are in html and i use them as containers often. i have
>> plenty
>> > of
>> > > links that have an icon and text, etc. im sure im not the only one
>> out
>> > > there.
>> > >
>> > > furthermore you just wont convince me that even if the link is just
>> a
>> > label
>> > > setting the text for it pragmatically is a widespread enough usecase
>> to
>> > > warrant this. the text is either in markup or in wicket:message tag
>> most
>> > of
>> > > the time.
>> > >
>> > >
>> > > > Yes we let them do that because we say that you have to make a
>> label
>> > for
>> > > > that.
>> > > > But again it is completely component oriented what i say... I see
>> the
>> > > > label
>> > > > as a property of the link!!
>> > >
>> > > How much more component oriented can that be? It is and will
>> always
>> > be
>> > > > in my eyes the display value of a link.
>> > >
>> > >
>> > > only if the link is not a container
>> > >
>> > > what you are trying to make link be here is sometimes a container
>> and
>> > > sometimes not - its totally wrong and confusing. why not push this
>> > feature
>> > > down into the webmarkupcontainer then? you can even get rid of Label
>> > then!
>> > >
>> > >
>> > > > I dislike a complete separate stack of links for that just
Re: Feature Idea / Request
> sorry ofcourse it is "wouldn't look like that"
>
> On 10/26/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>>
>> The LinkText would look like that (an label component added auto, what
>> is
>> the name of that label component then?)
Both can be easily solved.
1. The name for label can be some constant, you must only make sure it is
accessible (final method getLabelName())
2. You can then add it as one of constructors for Link and
AjaxFallBackLink and any other link you have in mind ...
Probably not what you want, but it can work.
saki
>>
>> But this doesn't work (having a seperate class), because now i want the
>> same thing but i want to use the AjaxFallBackLink? what then?
>> any kind of link we have now in core or extentions i could use the label
>> part.
>>
>> johan
>>
>>
>> On 10/26/06, Petr Sakar < [EMAIL PROTECTED]> wrote:
>> >
>> > Hi,
>> > I do not follow current development on 2.0, but it seems to me, that
>> > link with label is only 'specific' case of 'generic' link, so
>> extending
>> > Link class and introducing LinkText class (or whatever name you
>> choose)
>> > should make the trick.
>> >
>> > Something like:
>> >
>> > public class LinkText extends Link {
>> > final Label label;
>> > public LinkText(String name) {
>> > add(label = new Label());
>> > }
>> >
>> > and then you can have your methods to access label ...
>> >
>> > Probably you would have to change the check if markup for label exists
>> > as
>> > well, but as it is usually text only, it should not be big deal ...
>> >
>> > Or did I miss something ?
>> >
>> > saki
>> >
>> >
>> >
>> > > i am against it because i feel it perverts the api and the nature of
>> > > component orientation.
>> > >
>> > > if you think of it as a desktop link component then yeah text makes
>> > sense
>> > > there as a property because you cannot put anything else into a link
>> -
>> > > because most desktop link components dont let you - but in wicket
>> you
>> > can.
>> > >
>> > > just start a vote because obviously there is no middle ground here.
>> > >
>> > > -Igor
>> > >
>> > >
>> > > On 10/26/06, Johan Compagner <[EMAIL PROTECTED] > wrote:
>> > >>
>> > >> yuk!
>> > >> that doesn't help at all
>> > >> why ohh why would you trade this:
>> > >>
>> > >> new Link(this,"link").add(new Label())
>> > >> for
>> > >> new Link(this,"link").add(new BodyModifier())
>> > >>
>> > >> thats doesn't solve anything.
>> > >>
>> > >> Last thing i just say about this. Why do we constantly get this
>> > >> question??
>> > >> Because people see link text as the link text. I had exactly that
>> > same
>> > >> reaction from day 1
>> > >> I know jan blok also had that. I find it always so ugly that you
>> have
>> > to
>> > >> add
>> > >> a span inside a link and then add a label to the link component
>> > >> So i am +1 for adding getLabel() (and maybe setLabel()) to Link
>> > >> i am really -1 for introducing a completely seperate hierachy. Then
>> > just
>> > >> do
>> > >> nothing and let it be like it is now and let users implement there
>> > own
>> > >> when
>> > >> needed.
>> > >>
>> > >> I still don't get it why you guys are so against it it doesn't get
>> in
>> > >> your
>> > >> way at all. It is just a very nice and handy thing to have for all
>> > the
>> > >> people that think
>> > >> like me that the text of a link is the property of that link.
>> > >> And no you also have a lot of text that is dynamic and not i18n
>> like
>> > >> Listviews with data where an entry is directly a link. (that is
>> used
>> > all
>> > >> over the place in my solutions)
>> > >>
>> > >> johan
>> > >>
>> > >>
>> > >>
>> > >> On 10/26/06, Martijn Dashorst <[EMAIL PROTECTED] > wrote:
>> > >>
Feature Idea / Request for Panel like behavior for other components
Hi, currently (wicket 1.2) if I want to make component with own markup, I must extend Panel, or override some method to provide markup. Can you use as well interfaces to give framework hint that the component has its own markup in html template ? For example if component would implement interface BodyMarkup, the html template would be looked up. If it would implement interface HeadContributor, you would know it is contributing to page head. saki
Re: Feature Idea / Request for Panel like behavior for other components
> Can you be more specific as to why you don't want to inherit from > Border, Panel or Fragment? The usage is mainly for dynamic forms. 1. you define your components and their markup (TextField, DropDownChoice, ...) and some panel 2. adds them to panel, which is doing their layout to some table You can then write forms without need to write html templates for forms. Basically you would not have to use panel as wrapper instead of that you would be able to use existing components, subclass them to implement such interface and define their html template. I've alredy done such panel for one our project, and it works nice. It saves a lot of work ... saki > > Martijn > > On 10/27/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> Hi, >> currently (wicket 1.2) if I want to make component with own markup, I >> must >> extend Panel, or override some method to provide markup. >> Can you use as well interfaces to give framework hint that the component >> has its own markup in html template ? >> >> For example if component would implement interface BodyMarkup, the html >> template would be looked up. If it would implement interface >> HeadContributor, you would know it is contributing to page head. >> >> saki >> > > > -- > http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > at the http://www.thebeststuffintheworld.com/";>Best Stuff in > the World! >
Re: Feature Idea / Request for Panel like behavior for other components
ring exceptionMessage)
{
// Get markup associated with Border or Panel component
final MarkupStream originalMarkupStream = getMarkupStream();
final MarkupStream associatedMarkupStream =
getAssociatedMarkupStream(true);
// skip until the targetted tag is found
// String openTagName = "test";
//associatedMarkupStream.skipUntil(openTagName);
setMarkupStream(associatedMarkupStream);
// Get open tag in associated markup of border component
final ComponentTag associatedMarkupOpenTag =
associatedMarkupStream.getTag();
// Check for required open tag name
if (!((associatedMarkupOpenTag != null) &&
associatedMarkupOpenTag.isOpen() &&
(associatedMarkupOpenTag instanceof WicketTag)))
{
associatedMarkupStream.throwMarkupException(exceptionMessage);
}
try
{
setIgnoreAttributeModifier(true);
renderComponentTag(associatedMarkupOpenTag);
associatedMarkupStream.next();
renderComponentTagBody(associatedMarkupStream,
associatedMarkupOpenTag);
renderClosingComponentTag(associatedMarkupStream,
associatedMarkupOpenTag, false);
setMarkupStream(originalMarkupStream);
}
finally
{
setIgnoreAttributeModifier(false);
}
}
@SuppressWarnings ({"all"})
final void renderClosingComponentTag(final MarkupStream markupStream,
final ComponentTag openTag, final boolean renderTagOnly)
{
// Tag should be open tag and not openclose tag
if (openTag.isOpen())
{
// If we found a close tag and it closes the open tag,
we're good
if (markupStream.atCloseTag() &&
markupStream.getTag().closes(openTag))
{
// Get the close tag from the stream
ComponentTag closeTag = markupStream.getTag();
// If the open tag had its id changed
if (openTag.getNameChanged())
{
// change the id of the close tag
closeTag = closeTag.mutable();
closeTag.setName(openTag.getName());
}
// Render the close tag
if (renderTagOnly == false)
{
renderComponentTag(closeTag);
}
markupStream.next();
}
else
{
if (openTag.requiresCloseTag())
{
// Missing close tag
markupStream.throwMarkupException("Expected close tag for " + openTag);
}
}
}
}
public void setLayoutManager(ILayoutManager layoutManager) {
this.layoutManager = layoutManager;
}
public ILayoutManager getLayoutManager() {
return layoutManager;
}
}
> On 10/27/06, Petr Sakar <[EMAIL PROTECTED]> wrote:
>> > Can you be more specific as to why you don't want to inherit from
>> > Border, Panel or Fragment?
>>
>>
>> The usage is mainly for dynamic forms.
>> 1. you define your components and their markup (TextField,
>> DropDownChoice,
>> ...) and some panel
>> 2. adds them to panel, which is doing their layout to some table
>>
>> You can then write forms without need to write html templates for forms.
>>
>> Basically you would not have to use panel as wrapper instead of that you
>> would be able to use existing components, subclass them to implement
>> such
>> interface and define their html template.
>>
>> I've alredy done such panel for one our project, and it works nice.
>> It saves a lot of work ...
>> saki
>>
>> >
>> > Martijn
>> >
>> > On 10/27/06, Petr Sakar <[EMAIL PROTECTED]> wrote:
>> >> Hi,
>> >> currently (wicket 1.2) if I want to make component with own markup, I
>> >
Re: MarkupFragments and the vision to create a components in the constructor
Question / Idea: If I undestand it correctly, currently component hierarchy is build based on markup. How about to do it other way round ? For component hierarchy created in your java code lookup the markup ? saki
Re: MarkupFragments and the vision to create a components in the constructor
> that wont work, some components such as and > only exist in markup Igor, thank you for your answer. >From api doc: wicket:message="value=key" would replace or add the attribute "value" with the message associated with "key". I would expect it is implemented using AttributeModifier, not component. With wicket:link example you are right, but can be solved (you would have to add the component in code (or do some magic). Can you please give me other examples as well - I'm a bit curious and would like to find out if it is really impossible. Thanks saki > > -igor > > > On 11/3/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> >> Question / Idea: >> If I undestand it correctly, currently component hierarchy is build >> based >> on markup. How about to do it other way round ? For component hierarchy >> created in your java code lookup the markup ? >> >> saki >> >> >
Re: MarkupFragments and the vision to create a components in the constructor
> wicket:message tag attributes are replaced at markup load time, but > tags can not be replaced at load time. So you are replacing them with actual value at render time ? Than it has no influence with respect to original question: If I undestand it correctly, currently component hierarchy is build based on markup. How about to do it other way round ? For component hierarchy created in your java code lookup the markup ? > AttributeModifier must be attached to a Component, but the markup can > be associated with multiple component instances. Hence it must be > resolved at render time. > Just look at all the *Resolver to find out which components are > automatically added at render time > Magic is something we try to avoid. Magic is difficult to understand > by users and make the code more difficult to maintain. Simple and > straight forward is what we should aim for. > > Juergen Sorry for using word 'magic'. I'm trying to find out if such straight forward approach is possible - to create pages by specifying component hierarchy only in java code, and have markup only for components where it is needed. saki > > On 11/4/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> > that wont work, some components such as and >> >> > only exist in markup >> >> Igor, >> thank you for your answer. >> >> From api doc: >> wicket:message="value=key" would replace or add the attribute "value" >> with >> the message associated with "key". >> >> I would expect it is implemented using AttributeModifier, not component. >> >> With wicket:link example you are right, but can be solved (you would >> have >> to add the component in code (or do some magic). >> >> Can you please give me other examples as well - I'm a bit curious and >> would like to find out if it is really impossible. >> >> Thanks >> saki >> >> > >> > -igor >> > >> > >> > On 11/3/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> >> >> >> Question / Idea: >> >> If I undestand it correctly, currently component hierarchy is build >> >> based >> >> on markup. How about to do it other way round ? For component >> hierarchy >> >> created in your java code lookup the markup ? >> >> >> >> saki >> >> >> >> >> > >> >> >
Re: MarkupFragments and the vision to create a components in the constructor
Igor, thanx for very nice explanation. Still one more question for part I do not understand : if I'm in the rendering phase, I would suppose hierarchy is alredy known and I'm just creating the response, right? So why i'm adding for the tag wicket:message this auto component instead of just rendering the message to the response ? saki > On 11/4/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> >> > wicket:message tag attributes are replaced at markup load time, but >> > tags can not be replaced at load time. >> >> So you are replacing them with actual value at render time ? Than it has >> no influence with respect to original question: >> >> If I undestand it correctly, currently component hierarchy is build >> based on markup. How about to do it other way round ? For component >> hierarchy created in your java code lookup the markup ? > > > no, this is not how it works. the hierarchy is built in both places. the > hierarchy you build in your javacode has to match exactly to the hierarchy > you build in markup. > > the problem with components like wicket:message is that they have no java > counterpart, only markup. > > the render process is driven by scanning markup - because that is the only > place where the rendering order of components is defined. > > when we hit a markup component tag ( tag with wicket:id, or wicket > namespace > ) we try to resolve it to its java counterpart before it is rendered. this > is done by resolvers. since the default resolver fails to find the java > counterpart it delegates to other resolves in the chain. the wicketmessage > resolver kicks in. what it does is at render time add what we call an > "auto" > component - these are the only components allowed to be added/modify > hierarchy during the render phase. so wicketmessage resolver adds a label > component to represent the wicket:message tag. then the rendering > continues > and when wicket tries to resolve wicket:message it now finds the auto > component added by the resolver and everything continues as it normally > would. > > -igor >
Re: combination of Panel and FormComponent
> On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote: >> what makes a formcomponent a formcomponent? > > That, of course, is the main question :) But not an easy one, > certainly not to extract a robust interface from it. The component > like I proposed (but that should have the header stuff included) works > fine though, so this might be a better solution than forcing ourselves > into interfaces when we're still unsure about what the best are. > > Eelco > May would be interesting to try it from the other end - what makes Panel a panel ? A lot of components (not only form) can have except its own behaviour the behaviour of panel ... saki
Re: combination of Panel and FormComponent
> I agree with that remark, and like the idea of components attaching to > markupfiles whatever kind of component they are. However, what we'd > gain in flexibility by getting rid of Panel (hypothetically), we'd > loose in clarity. If you wouldn't explicitly instantiate a panel that > matches markup, how would things work? What if you have a markup file One of many solutions would be to use interfaces to give hint to framework, how the component behaves. For example the component can implement interface HasAssociatedMarkup, IsBorder, IsHeaderContributor, ... > that matches the component class and that has both and > tags? What about a border fragment attached to a text > field? Probably wrong markup file. What will happen today if you create such markup for Panel ? > > It also might be quite tedious to implement. More people have thoughts on > this? > > Eelco > > On 12/12/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> > On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote: >> >> what makes a formcomponent a formcomponent? >> > >> > That, of course, is the main question :) But not an easy one, >> > certainly not to extract a robust interface from it. The component >> > like I proposed (but that should have the header stuff included) works >> > fine though, so this might be a better solution than forcing ourselves >> > into interfaces when we're still unsure about what the best are. >> > >> > Eelco >> > >> May would be interesting to try it from the other end - what makes Panel >> a >> panel ? A lot of components (not only form) can have except its own >> behaviour the behaviour of panel ... >> saki >> >
Re: combination of Panel and FormComponent
> hmm i do like to separate the components with its own markup and the onces > that dont > > johan > I would say the division should be different. Component which needs markup (markup is provided either by parent component or is their own) and the ones that don't. Would be very nice if you can easy say, which case it is and easily change it as well. Some components can generate all markup, so there is no need to look for some. > > On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> >> I agree with that remark, and like the idea of components attaching to >> markupfiles whatever kind of component they are. However, what we'd >> gain in flexibility by getting rid of Panel (hypothetically), we'd >> loose in clarity. If you wouldn't explicitly instantiate a panel that >> matches markup, how would things work? What if you have a markup file >> that matches the component class and that has both and >> tags? What about a border fragment attached to a text >> field? >> >> It also might be quite tedious to implement. More people have thoughts >> on >> this? >> >> Eelco >> >> On 12/12/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> > > On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote: >> > >> what makes a formcomponent a formcomponent? >> > > >> > > That, of course, is the main question :) But not an easy one, >> > > certainly not to extract a robust interface from it. The component >> > > like I proposed (but that should have the header stuff included) >> works >> > > fine though, so this might be a better solution than forcing >> ourselves >> > > into interfaces when we're still unsure about what the best are. >> > > >> > > Eelco >> > > >> > May would be interesting to try it from the other end - what makes >> Panel >> a >> > panel ? A lot of components (not only form) can have except its own >> > behaviour the behaviour of panel ... >> > saki >> > >> >
Bean properties
Can be of some use for wicket ? http://www.theserverside.com/news/thread.tss?thread_id=44804 https://bean-properties.dev.java.net/ saki
