The way my framework is set up, I've got a PropertyEditorFactory interface:
public interface PropertyEditorFactory
{
public Component createPropertyEditor(String componentName, Object
target, PropertyMetadata meta);
}
If I required my factory to return Panel objects instead, where would
the markup for those Panels come from? Would I have to write my own
Panel extension classes that have the different editor types in them
(TextEditorPanel, BooleanEditorPanel, etc.)?
On 1/20/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> instead of using fragments you can use panels, which would make the
> editors reusable across projects/pages.
>
> as far as "why" the checks are there...
>
> add(new TextField("foo"));
> <div wicket:id="foo"/>
>
> will end up with
>
> <div wicket:id="foo" value="bar"/> <== not a very useful textbox
>
> wicket does not mutate markup by default, so it will not mutate div
> tag to input tag.
>
> it also adds a level of error checking, making sure you add the right
> components to the right places.
>
> -igor
>
>
> On Jan 20, 2008 1:50 PM, James Carman <[EMAIL PROTECTED]> wrote:
> > So, the key is to use Fragments? This is very similar to how we did
> > it in Trails. I would like to make this somewhat reusable in other
> > projects so that they can define their own "editors" without having to
> > change this framework code. I'm somewhat new to Wicket, so maybe I
> > just don't understand this all yet, but it seems to me like this
> > framework will only be able to use Fragments defined within the
> > current markup (the BeanEditPanel.html file). Is that true? In
> > Trails, we had the concept of a "component address" that you would
> > use to locate the editor component you want to use. So, it could be
> > defined in another page supplied by the user. Trails comes with a
> > default page containing all of its editors as "Blocks" (similar to a
> > Fragment). The default behavior returns components from this page as
> > the editors for properties. However, any client application could
> > define their own editor component blocks on some page and use those
> > also.
> >
> >
> > On 1/20/08, Gerolf Seitz <[EMAIL PROTECTED]> wrote:
> > > have you seen Al's "Bean Editor" [0]?
> > > this might give you a hint in the right direction.
> > >
> > > regards,
> > > gerolf
> > >
> > > [0] http://herebebeasties.com/2007-08-17/wicket-bean-editor/
> > >
> > > On Jan 20, 2008 10:17 PM, James Carman <[EMAIL PROTECTED]> wrote:
> > >
> > > > Is there any reason that components require that they be applied to
> > > > specific tag types in the markup files? I'm writing a little utility
> > > > which calculates at runtime what "editor" to use based on the property
> > > > type (a la Trails). So, I have no idea what type of tag to use. I
> > > > thought I'd just do this (the actual component is a TextField in this
> > > > case):
> > > >
> > > > <div wicket:id="editor" />
> > > >
> > > > But, I get the following error message:
> > > >
> > > > org.apache.wicket.markup.MarkupException: Component editor must be
> > > > applied to a tag of type 'input', not '<div wicket:id="editor">' (line
> > > > 0, column 0)
> > > >
> > > > If I change my markup to:
> > > >
> > > > <input type="text" wicket:id="editor" />
> > > >
> > > > then it works. But, suppose a certain property requires a more
> > > > complicated "editor" component (maybe rich text, so I'd use something
> > > > like FCKEditor). Would that component be complaining that it's being
> > > > applied to an <input> tag? Is there any generic way to do this so
> > > > that all components will be happy at runtime with the markup? Is
> > > > there any way to relax that restriction?
> > > >
> > > > James
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
