See my answers below.
Hi Tobias, thanks for the answers.
Or with a new dedicated annotation, annotations with too many attributes
are just a pain to use.
Uhm... Yes and no. I like annotation with (reasonable) attributes,
because usually are used to configure every aspect of something
self-contained. I don't like them when there is strong inheritance
involved with little changes at each level. Having many different
annotations may be a pain as well, so I suppose it's just a matter of
tastes.
For example, I still don't get why @ParagraphDescription is not a simple
parameter of @Paragraph but a separate annotation. :-)
Could you describe in more the detail the problems you're having with
the select control. You should be able to create it from scratch or read
it configured from the repository and then modify it as you like.
Select is just the first example I stumbled upon in my project.
Select is a wonderful control that has a lot of options to configure. I
wanted to use it to show as options a list of nodes. To do this in the
normal configuration, you have to set a few properties in the repo:
"path", "repository", "valueNodeData" and "labelNodeData". But you can't
do the same in Blossom esaly like this: there is no build in method in
TabBuilder, but that's not a problem. If you use
DialogFactory.getDialogSelectInstance, you will notice that setting
those properties in the config afterwards have no effect, because the
configuration in the select is done in the "init" method, that expects
to have all properties already set. So you can either copy/paste from
the DialogSelect the part of code that adds the options to the select
and use it in your code, or configure a node in the repo for that
select, load it and pass it to the
DialogFactory.getDialogSelectInstance. The latter is the solution I
used, but left me with the impression that I was defying the original
idea of having configurable dialogs in Blossom. Or at least that there
is still a missing spot for controls that needs all configuration
properties already set before being instanced by the factory. Maybe it's
just me seeing a problem that doesn't really exists.
You can use class inheritance to share a tab between many pargraphs and
dialogs. Just create an abstract base class and annotate a method in it
with @TabFactory.
Yes, of course.
Maybe it would also help to have @TabFactory annotated with @Interited,
but I don't know if that would introduce side effects.
There's currently no built-in support for setting the savehandler on the
controller. You'll need to extend Blossom for that. What you can do is
extend DefaultBlossomDialogRegistry and set the savehandler there, it
could check for a custom annotation or invoke a method on the controller
to find out. For paragraphs however, since they create their own dialogs
without registering them in the repository, you'll have to subclass
BlossomParagraphEditDialog.
Yes, I made a patch and opened BLOSSOM-14, if you have time to look at
it. The real problem was that DialogMVCHandler was not too easy to have
saveHandler setted by subclasses, I had to use reflections...
Please do =)
Opened as BLOSSOM-15. Thank you.
Regards, Danilo.
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
