Hi Danilo,
See my answers below.
>
> 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.
Or with a new dedicated annotation, annotations with too many attributes are
just a pain to use.
>
>> 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.
>
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.
>> 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... :-)
>
Yes =)
>> 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).
>
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.
>> 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 :-)
>
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.
>> 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? :-)
>
Please do =)
> Regards, Danilo.
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
