Home » Archived » BIRT » User Properties in Styles
| User Properties in Styles [message #27193] |
Sun, 17 April 2005 11:33  |
Eclipse User |
|
|
|
Originally posted by: mbatchelor.no_s_p_a_m.pentaho.com
Hey all,
Can we get the ROM spec modified to allow styles (or any other part of the
model) to have user properties? I can add user properties to data-sets,
data-sources, parameters, parameter groups, etc. But, for some reason,
styles cannot have user properties.
Thanks,
Marc
|
|
|
| Re: User Properties in Styles [message #27305 is a reply to message #27193] |
Sun, 17 April 2005 21:28  |
| Eclipse User |
|
|
|
Originally posted by: mbatchelor.no_s_p_a_m.pentaho.com
I modified my local rom.def to allow user properties on styles. Everything
works fine, and I can now define user properties on Styles. What're the
chances of getting this rolled into the baseline?
Thanks,
Marc
"Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
news:d3u01k$n6c$1@news.eclipse.org...
> Hey all,
>
> Can we get the ROM spec modified to allow styles (or any other part of the
> model) to have user properties? I can add user properties to data-sets,
> data-sources, parameters, parameter groups, etc. But, for some reason,
> styles cannot have user properties.
>
> Thanks,
>
> Marc
>
>
|
|
|
| Re: User Properties in Styles [message #28258 is a reply to message #27305] |
Tue, 19 April 2005 14:56 |
| Eclipse User |
|
|
|
Marc,
BIRT will allow user properties on elements, but we've been thinking that
user properties won't be available on styles. At this point, it is not clear
if that functionality will make Release 1.0, but it is on the roadmap.
We recommend against modifying rom.def for the obvious compatibility
reasons. There will be a separate system (using the User Property definition
defined in the ROM spec) to add the properties.
Indeed, the model already supports them if you were to use a text editor to
add the user property definitions to an XML design file. I believe that they
may even show up in the property sheet. However, this has not yet been fully
tested.
Out of curiosity, how will you use your custom properties? Are they
associated with a report item? With your application? What info will they
hold? How would you make use of user properties on styles, if BIRT were to
support them? Info about actual use cases is always very helpful!
Thanks,
- Paul
Paul Rogers
BIRT PMC
"Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
news:d3v2u2$r6m$1@news.eclipse.org...
>I modified my local rom.def to allow user properties on styles. Everything
> works fine, and I can now define user properties on Styles. What're the
> chances of getting this rolled into the baseline?
>
> Thanks,
>
> Marc
>
> "Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
> news:d3u01k$n6c$1@news.eclipse.org...
>> Hey all,
>>
>> Can we get the ROM spec modified to allow styles (or any other part of
>> the
>> model) to have user properties? I can add user properties to data-sets,
>> data-sources, parameters, parameter groups, etc. But, for some reason,
>> styles cannot have user properties.
>>
>> Thanks,
>>
>> Marc
>>
>>
>
>
|
|
|
| Re: User Properties in Styles [message #28409 is a reply to message #28258] |
Tue, 19 April 2005 21:11 |
| Eclipse User |
|
|
|
Originally posted by: mbatchelor.no_s_p_a_m.pentaho.com
Hi Paul,
User properties are generally useful on any element because they create the
ability store state within any section of the report definition. I'm not
sure if I can say what I'm exactly doing with the user properties at this
point (we're under development), but suffice it to say that we need the
ability to tag any section of the report definition with our own properties.
Since it's only a matter of changing the "allowsUserProperties" from false
to true in the rom.def, it should be no problem technically. Even if your
tool doesn't support creating them, other extensions and plugins can and
will be able to tag any section in the report definition with additional
data.
So for example, in the rom.def, the line looks like this:
<Element name="Style"
javaClass="org.eclipse.birt.report.model.elements.Style"
displayNameID="Element.Style" isAbstract="false" extends="ReportElement"
allowsUserProperties="false" canExtend="false" hasStyle="false"
nameSpace="style" isNameRequired="true">
All I had to do is change it to this:
<Element name="Style"
javaClass="org.eclipse.birt.report.model.elements.Style"
displayNameID="Element.Style" isAbstract="false" extends="ReportElement"
allowsUserProperties="true" canExtend="false" hasStyle="false"
nameSpace="style" isNameRequired="true">
A one word change. I also modified the rom.def to allow user properties in
most places that had allowsUserProperties set to false. It's not a major
change, and it doesn't require any additional code to be written. It does
however open major functionality for extensibility at no programming cost.
So it's a win/win situation.
Should I write a bugzilla case on this?
Hope this helps,
Marc
"Paul Rogers" <progers@actuate.com> wrote in message
news:d43kom$tnh$1@news.eclipse.org...
> Marc,
>
> BIRT will allow user properties on elements, but we've been thinking that
> user properties won't be available on styles. At this point, it is not
clear
> if that functionality will make Release 1.0, but it is on the roadmap.
>
> We recommend against modifying rom.def for the obvious compatibility
> reasons. There will be a separate system (using the User Property
definition
> defined in the ROM spec) to add the properties.
>
> Indeed, the model already supports them if you were to use a text editor
to
> add the user property definitions to an XML design file. I believe that
they
> may even show up in the property sheet. However, this has not yet been
fully
> tested.
>
> Out of curiosity, how will you use your custom properties? Are they
> associated with a report item? With your application? What info will they
> hold? How would you make use of user properties on styles, if BIRT were to
> support them? Info about actual use cases is always very helpful!
>
> Thanks,
>
> - Paul
>
> Paul Rogers
> BIRT PMC
>
>
> "Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
> news:d3v2u2$r6m$1@news.eclipse.org...
> >I modified my local rom.def to allow user properties on styles.
Everything
> > works fine, and I can now define user properties on Styles. What're the
> > chances of getting this rolled into the baseline?
> >
> > Thanks,
> >
> > Marc
> >
> > "Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
> > news:d3u01k$n6c$1@news.eclipse.org...
> >> Hey all,
> >>
> >> Can we get the ROM spec modified to allow styles (or any other part of
> >> the
> >> model) to have user properties? I can add user properties to data-sets,
> >> data-sources, parameters, parameter groups, etc. But, for some reason,
> >> styles cannot have user properties.
> >>
> >> Thanks,
> >>
> >> Marc
> >>
> >>
> >
> >
>
>
|
|
|
| Re: User Properties in Styles [message #28486 is a reply to message #28409] |
Wed, 20 April 2005 01:57 |
| Eclipse User |
|
|
|
Marc,
Yes, this helps quite a bit. As you can see, we did make the model general
enough to handle user properties on styles, but then got cold feed and
backed off, wondering if we were making things too complex...
BIRT also provides an XML way to tag elements with your own data; within the
customXML property you can include your own XML (or anything, really.) User
properties require a property definition, custom XML does not.
Also, on the drawing board, but not yet in the APIs, is the ability for your
app to extend existing items with new properites. For example, say you want
to add the "foo" properties to all styles. This new extension point will
allow you to do so.
Given these three choices (user properties, custom XML and property
extension APIs), which would work best for your app?
And, please do file a bugzilla entry for the user property change. That way
I can point the model team to your entry.
Thanks,
- Paul
Paul Rogers
BIRT PMC
"Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
news:d44a8q$jn6$1@news.eclipse.org...
> Hi Paul,
>
> User properties are generally useful on any element because they create
> the
> ability store state within any section of the report definition. I'm not
> sure if I can say what I'm exactly doing with the user properties at this
> point (we're under development), but suffice it to say that we need the
> ability to tag any section of the report definition with our own
> properties.
>
> Since it's only a matter of changing the "allowsUserProperties" from false
> to true in the rom.def, it should be no problem technically. Even if your
> tool doesn't support creating them, other extensions and plugins can and
> will be able to tag any section in the report definition with additional
> data.
>
> So for example, in the rom.def, the line looks like this:
>
> <Element name="Style"
> javaClass="org.eclipse.birt.report.model.elements.Style"
> displayNameID="Element.Style" isAbstract="false" extends="ReportElement"
> allowsUserProperties="false" canExtend="false" hasStyle="false"
> nameSpace="style" isNameRequired="true">
>
> All I had to do is change it to this:
>
> <Element name="Style"
> javaClass="org.eclipse.birt.report.model.elements.Style"
> displayNameID="Element.Style" isAbstract="false" extends="ReportElement"
> allowsUserProperties="true" canExtend="false" hasStyle="false"
> nameSpace="style" isNameRequired="true">
>
> A one word change. I also modified the rom.def to allow user properties in
> most places that had allowsUserProperties set to false. It's not a major
> change, and it doesn't require any additional code to be written. It does
> however open major functionality for extensibility at no programming cost.
> So it's a win/win situation.
>
> Should I write a bugzilla case on this?
>
> Hope this helps,
>
> Marc
>
>
>
> "Paul Rogers" <progers@actuate.com> wrote in message
> news:d43kom$tnh$1@news.eclipse.org...
>> Marc,
>>
>> BIRT will allow user properties on elements, but we've been thinking that
>> user properties won't be available on styles. At this point, it is not
> clear
>> if that functionality will make Release 1.0, but it is on the roadmap.
>>
>> We recommend against modifying rom.def for the obvious compatibility
>> reasons. There will be a separate system (using the User Property
> definition
>> defined in the ROM spec) to add the properties.
>>
>> Indeed, the model already supports them if you were to use a text editor
> to
>> add the user property definitions to an XML design file. I believe that
> they
>> may even show up in the property sheet. However, this has not yet been
> fully
>> tested.
>>
>> Out of curiosity, how will you use your custom properties? Are they
>> associated with a report item? With your application? What info will they
>> hold? How would you make use of user properties on styles, if BIRT were
>> to
>> support them? Info about actual use cases is always very helpful!
>>
>> Thanks,
>>
>> - Paul
>>
>> Paul Rogers
>> BIRT PMC
>>
>>
>> "Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
>> news:d3v2u2$r6m$1@news.eclipse.org...
>> >I modified my local rom.def to allow user properties on styles.
> Everything
>> > works fine, and I can now define user properties on Styles. What're the
>> > chances of getting this rolled into the baseline?
>> >
>> > Thanks,
>> >
>> > Marc
>> >
>> > "Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
>> > news:d3u01k$n6c$1@news.eclipse.org...
>> >> Hey all,
>> >>
>> >> Can we get the ROM spec modified to allow styles (or any other part of
>> >> the
>> >> model) to have user properties? I can add user properties to
>> >> data-sets,
>> >> data-sources, parameters, parameter groups, etc. But, for some reason,
>> >> styles cannot have user properties.
>> >>
>> >> Thanks,
>> >>
>> >> Marc
>> >>
>> >>
>> >
>> >
>>
>>
>
>
|
|
|
| Re: User Properties in Styles [message #29034 is a reply to message #28486] |
Wed, 20 April 2005 11:41 |
| Eclipse User |
|
|
|
Originally posted by: mbatchelor.no_s_p_a_m.pentaho.com
> Yes, this helps quite a bit. As you can see, we did make the model general
> enough to handle user properties on styles, but then got cold feed and
> backed off, wondering if we were making things too complex...
IMO, making things extensible often makes things complex on the inside, with
the upside of making it easy on the outside. Your mechanism for persistence
to XML is a fine example of this. It's complex code with the upside of
making the XML very human-friendly.
> BIRT also provides an XML way to tag elements with your own data; within
the
> customXML property you can include your own XML (or anything, really.)
User
> properties require a property definition, custom XML does not.
Yes, and I can see good arguments on each side for each one. I like the user
properties route (personally) because we define the property up front, and
that definition can be used to build UI components. Random hunks of XML
slammed into a node are really not very self-documenting, and I think they
subvert the human-readability of the model. That's why I want to be able to
use User Properties on styles, and in other places like the top-level
report.
> Also, on the drawing board, but not yet in the APIs, is the ability for
your
> app to extend existing items with new properites. For example, say you
want
> to add the "foo" properties to all styles. This new extension point will
> allow you to do so.
For our use, if a user does something specific with one or two styles, we
want to be able to store state with that style (or data source, or data set,
etc.) So, it's not adding a property to every style that would be useful in
this case (although I can see where this would be cool for something else we
have in mind).
> Given these three choices (user properties, custom XML and property
> extension APIs), which would work best for your app?
Certainly not custom XML (although I think this IS an important capability).
I'd want to see more about the property extension API, but it sounds less
like what we need at this point than User Properties.
> And, please do file a bugzilla entry for the user property change. That
way
> I can point the model team to your entry.
Done.
Thanks for your time,
Marc
|
|
| |
Goto Forum:
Current Time: Wed May 07 03:19:35 EDT 2025
Powered by FUDForum. Page generated in 0.08981 seconds |
Home