Thank you for the anskwer.
At one point i was considering adding support for dialog "inheritance" that
would've worked like this:
@DialogFactory(value="my-dialog", prototype="some-other-dialog")
public class MyDialog {
}
That would have been really nice, it was what I had in mind, more or
less. Obviously the same should go in the @Paragraph annotation.
When my-dialog is created it will include all the tabs and controls of
some-other-dialog.
That way you could configure some parts of your dialog in the repository, under
a different dialog name.
That would be indeed good (and cover most of the use cases), but still
to be honest a little piece would be missing. Unfortunately some
controls ("select" above all) will set up correctly only if they already
have everything in the configuration node passed to the init method. But
I think that case is the most difficult to cover with annotations, so
it's ok to leave it to the user code.
A @TabFactory("Content") method would not create a new tab if one with the label
"Content" already exists, instead it would add controls to it.
I suppose when you have the right instance of tab you can also remove
controls in the code, so this should cover every case.
I hope the matching of the label is done before i18n... :-)
In the end i decided not to include it because i didnt see a need for it and
its pretty complex.
Does this idea solve your problem?
Yes, it would solve a big part of the problem, and I suppose it would be
pretty complex because I'm having my share of problems just trying to
handle it with "simple" code without rewriting Blossom.
My "problem" now is that for my first use of Blossom I get one of the
worst use cases I have ever seen: I have a few dialogs in which a part
of the data, even being edited by Magnolia, is read from and stored in
another source. Plus the fact that a few controls should be there or not
depending on data. Plus the fact that one tab is (or should be) shared
among almost all dialogs.
If you imagine that the "external source" is somewhere in the data
module (and not handled by spring as in my case), you could see that the
use case is not too strange to imagine. Reading from the source and
hiding controls is easy with Blossom (except when setting a select, but
just because it's a little verbose to load the options). Sharing the tab
is easy in Magnolia using the "reference" property, but in Blossom you
have to copy all controls from the source tab to the tab passed to the
@TabFactory. Also it's not easy to implement a saveHandler to save part
of the data to the other source (or at least this is the point where I'm
struck at the moment).
Perhaps you might also require a @TabFactory(value="Content",
prototype="/config/modules/myModule/dialogs/dialog/tab/title") ?
Yes, obviously! :-) And I'll require also an annotation that would allow
one method to override the standard saveHandler for the dialog :-)
Another way of solving this is just doing what you're already doing but
abstracting the logic to a helper class.
In the end I used this solution, just because I don't know what is the
developing plan for Blossom. Is it ok to open a new feature request for
what you write above? :-)
Regards, Danilo.
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
