Hi Hitesh,
The demo project of the plugin doesn't include any HST content bean
examples intentionally because the plugin itself is originally about
how to add a custom field to select external resources in CMS
authoring UI. That's the focus here. If we keep the demo project with
all the variety of hst code examples, then it might be too much to
maintain, IMO.
I think it's trivial to add getter method in your HST content bean to
read your custom field or child node (set by the plugin in the
authoring UI).
Also, the *example* in the page, ExampleExternalDocumentServiceFacade,
is just an example. You shouldn't regard it as a base code you can use
right away. In that specific example, for simplicity, it stores the
data in a property, but there are a lot of different examples doing in
different ways.
For example, in my experience, my customer wants to create mirror
nodes (doc/image/asset link field) when selecting external resources.
Anyway, there can be too many different implementations.
So, I intended to keep the demo project as simple as possible, only
focusing on authoring UI extension. Yeah, a good thing of external
document picker plugin is that you don't have to specify a physical
property or compound nodes tightly with the editor:template field UI
component configuration. It's only about UI (which the plugin
provides) in the end. :-)
Anyway, in your case, you should add a getter by yourself based on
your facade implementation because you know all about your facade
implementation and how it stores the data physically.
You might think it's not so consistent with the bean generator in
essentials. Yeah, the tool does its job based on physical document
node definitions, not considering this kind of *extensible* community
driven plugins. We are open to any good ideas to improve it though.
Kind regards,
Woonsan
--
w....@onehippo.com www.onehippo.com
Boston - 745 Atlantic Ave, 8th Floor, Boston MA 02111
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
US
+1 877 414 4776 (toll free)
Europe
+31(0)20 522 4466