felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: metatype extension
Date Wed, 04 Mar 2015 04:58:19 GMT
On Tue, Mar 3, 2015 at 6:25 PM, David Jencks <david_jencks@yahoo.com.invalid
> wrote:

> I haven't looked in detail at what you are proposing.
>
> The eclipse metatype impl supports pretty much arbitrary extra attributes
> in extension namespaces.  I'd start by implementing something like that in
> the felix metatype impl.  It won't help much with metatype providers unless
> they happen to generate felix or equinox specific goo. I don't think
> there's any plausible way around this yet.
>

I'm pretty ok with having to use felix specific goo in any metatype
providers we might implement, if we chose to make metatype providers, that
is.

Therefore I was thinking of just a very simple runtime annotation one would
place on the OCDs and ADs returned from a metatype provider.

public @interface Attributes {
    String[] attributes() default {};
}

where the same scheme as DS' @Component property (minus the types) is used.

These would get siphoned into the existing OptionalAttributes object.

I have an untested prototype with all these changes in place already just
to see what it would look like.


>
> I'm pushing for an extension annotation processor plugin-plugin thingy for
> bnd https://github.com/bndtools/bnd/pull/838 that would let you write
> some felix specific annotations and get the info into the metatype xml.
>

Cool, I was thinking of exactly something like this as well. I'll take a
closer look at the PR.


>
> The proprietary metatype framework I work with uses the pid of the
> "target" configuration for "foreign key" references.


I'd really just like to be able to mark some AD as readonly from the point
of view of the UI (that is, on updates). At least this way, when a
configuration is created programmatically (where the pKey value would be
set), there'd be _less_ chance that someone comes along later and borks it
up by messing with the value.

- Ray


>
> thanks
> david jencks
>
>
>
> On Mar 3, 2015, at 2:29 PM, Raymond Auge <raymond.auge@liferay.com> wrote:
>
> > Some searching lead to another request for something like this at least
> > here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/felix-dev/201301.mbox/%3C2B034BDA9437584AA6A714D3DFE23238CA6FC6@Eleos.SIDON.OLYMP%3E
> >
> > - Ray
> >
> > On Tue, Mar 3, 2015 at 10:36 AM, Raymond Auge <raymond.auge@liferay.com>
> > wrote:
> >
> >>
> >>
> >> On Tue, Mar 3, 2015 at 10:32 AM, Jan Willem Janssen <
> >> janwillem.janssen@luminis.eu> wrote:
> >>
> >>> Hi Raymond,
> >>>
> >>>> On 03 Mar 2015, at 16:24, Raymond Auge <raymond.auge@liferay.com>
> >>> wrote:
> >>>> […]
> >>>> However, a metatype implementation change would be required but ONLY
> for
> >>>> access to said new "hints" information. This would require:
> >>>>
> >>>> 1) reading the extra schema info while parsing the metatype xml
> >>>> 2) providing API access to the information
> >>>>
> >>>> Implementing
> >>>> 1) is simple, just need to enhance the parser with the fields we
> decide
> >>>> 2) I was thinking of something like the following:
> >>>> […]
> >>>
> >>> IIRC, the MetaType spec already allows for optional attributes to be
> >>> defined
> >>> on ADs, Attributes, OCDs and Objects. I believe that this would already
> >>> cover
> >>> most of these requirements, not?
> >>>
> >>
> >> Sure! However, the need to read the metatype again is painful when
> >> metatype is already reading it. Furthermore, this doesn't work for
> >> MetatypeProviders.
> >>
> >> - Ray
> >>
> >>
> >>>
> >>> --
> >>> Met vriendelijke groeten | Kind regards
> >>>
> >>> Jan Willem Janssen | Software Architect
> >>> +31 631 765 814
> >>>
> >>> My world is revolving around INAETICS and Amdatu
> >>>
> >>> Luminis Technologies B.V.
> >>> Churchillplein 1
> >>> 7314 BZ   Apeldoorn
> >>> +31 88 586 46 00
> >>>
> >>> http://www.luminis-technologies.com
> >>> http://www.luminis.eu
> >>>
> >>> KvK (CoC) 09 16 28 93
> >>> BTW (VAT) NL8169.78.566.B.01
> >>>
> >>>
> >>
> >>
> >> --
> >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> >> (@rotty3000)
> >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> >> (@Liferay)
> >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> >> (@OSGiAlliance)
> >>
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message