Well, custom editor components based on object type sounds in scope for what
I have in mind. And, yes, I'm planning on implementing something similar to
Trails using Wicket (and I was planning on calling it "wails").
On 1/21/08, Johan Maasing <[EMAIL PROTECTED]> wrote:
>
> Yes that would be fun and a great way to learn more wicket. Are you
> doing a fork of trails (wrails)?
> Primarily what I am interested in is web content management and
> publishing. I'm looking to replace/enhance a legacy system that bases
> its' rendering on velocity or XML-based views. As a start I would
> like to write a simple (but functional) publishing system based on
> wicket. What I'm looking for is coding specific editors and display
> components based on the content type. The content type is, I guess,
> basically a domain object like editorial, flash and so on. Does it
> sound like enough overlap with your interests to actually start a
> project?
>
> 2008/1/21, James Carman <[EMAIL PROTECTED]>:
> > Or, maybe we should start a new project (or a Wicket subproject) to take
> > care of this common need.
> >
> > On 1/21/08, Johan Maasing <[EMAIL PROTECTED]> wrote:
> > >
> > > As an exercise I tried to write a CMS-like framework. It became
> > > remarkably similiar and I had the same question. My factories produced
> > > an editor and a display, apart from that they have almost the same
> > > names as yours. I guess this almost qualifies as a FAQ :-)
> > >
> > > 2008/1/20, James Carman <[EMAIL PROTECTED]>:
> > > > 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]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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]
>
>
