You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Adam Winer <aw...@gmail.com> on 2007/04/04 22:42:17 UTC
Re: return an Iterator vs a List
If the only reason is to enable the fun new "for" syntax,
then we should change the type from Iterator to Iterable,
instead of List. List is a much larger contract.
-- Adam
On 3/28/07, Jeanne Waldman <je...@oracle.com> wrote:
> Hi there,
> I'm in the Skinning StyleNode code and I see that the 'get' methods
> return Iterators
> from the good ol' days.
> It seems to me that it is better if they just return Lists so the code
> that iterates over
> the values is cleaner using 5.0's for(String foo : yyy) construct.
> Does anyone see why I wouldn't want these to return List instead of
> Iterator?
>
> Here's a code snippet. Thanks, Jeanne
> --
>
> public Iterator<IncludePropertyNode> getIncludedProperties()
> {
> if(_includedProperties == null)
> {
> List<IncludePropertyNode> list = Collections.emptyList();
> return list.iterator();
> }
> else
> return (Arrays.asList(_includedProperties)).iterator();
> }
>
> /**
> * Gets the properties specified by this node's parent that should be
> * ignored. This method will return an empty iterator if
> * {@link #isInhibitingAll()} returns <code>true</code>
> *
> * @return an iterator over the properties that should be ignored, an
> * empty iterator if all properties should be.
> */
> public Iterator<String> getInhibitedProperties()
> {
> if(_inhibitedProperties == null)
> {
> List<String> list = Collections.emptyList();
> return list.iterator();
> }
> else
> {
> return _inhibitedProperties.iterator();
> }
> }
>
localize logging/exception message
Posted by Jijun Wang <ji...@oracle.com>.
Please comment/approve:
https://issues.apache.org/jira/browse/ADFFACES-441
Proposal:
1) use resource bundle for logging message in java files above fine level so those message could be localized;
2) localize part/all exception in java files with resource bundle
Benefit:
More information in local language accessible for people in tech support, operation, deployment, field application etc whose software uses trinidad code
Details:
Trinidad-api and trinidad-impl will have their own LoggerBundle.xrts where message to be localized is defined. A LoggerUtils class will be added as a decorator in each project. LoggerUtils.createTrinidadLogger will return a TrinidadLogger instance with appropriate resource bundle attached. Message localization in logging is thus available from java logging by inheritance. Localization in exception message is achieved by passing localized message to exception. For both logging and exception, server locale will be used. This might create inconsistency for exception when client locale and server locale are different. Since an exception not captured would show both on server logger and client browser, using server locale is more practical.
Open Issues:
1) Current API in TrinidadLogger is not enough to handle logging that contains message, message parameters and throwable. e.g
_LOG.warning("Unable to instantiate converterClass:" + converterName, e); would become:
_LOG.warning("UNABLE_INSTANTIATE_CONVERTERCLASS", converterName, e); or
_LOG.logp(Level.WARNING, ..."UNABLE_INSTANTIATE_CONVERTERCLASS", converterName, e)
But we neither warning() nor logp() has API that would take (...String message, Object parm, throwable e) as signature. Should we add API or use 2 logging statements?
_LOG.warning("Unable to instantiate converterClass:" + converterName;
_LOG.warning(e);
2) Should LoggerUtils provide some methods like public static String getMessage(TrinidadLogger logger, String key (, Object params([])?)?) to retrieve localized string from resource bundle(parameter substitution could also be done in the method). The alternative is to use TrinidadLogger.getResourceBundle.getString(key) to retrieve localized message(in this case no parameter substitution or we don't localize exception message that carries parameters)
Re: return an Iterator vs a List
Posted by Jeanne Waldman <je...@oracle.com>.
This is the case. It is really to use the fun new "for" syntax. At least
for now.
- Jeanne
Simon Lessard wrote:
> In that specific case Iterable would be nice yeah.
>
> On 4/5/07, Matthias Wessendorf <ma...@apache.org> wrote:
>>
>> +1
>>
>> On 4/5/07, Adam Winer <aw...@gmail.com> wrote:()
>> > If the only reason is to enable the fun new "for" syntax,
>> > then we should change the type from Iterator to Iterable,
>> > instead of List. List is a much larger contract.
>> >
>> > -- Adam
>> >
>> >
>> > On 3/28/07, Jeanne Waldman <je...@oracle.com> wrote:
>> > > Hi there,
>> > > I'm in the Skinning StyleNode code and I see that the 'get' methods
>> > > return Iterators
>> > > from the good ol' days.
>> > > It seems to me that it is better if they just return Lists so the
>> code
>> > > that iterates over
>> > > the values is cleaner using 5.0's for(String foo : yyy) construct.
>> > > Does anyone see why I wouldn't want these to return List instead of
>> > > Iterator?
>> > >
>> > > Here's a code snippet. Thanks, Jeanne
>> > > --
>> > >
>> > > public Iterator<IncludePropertyNode> getIncludedProperties()
>> > > {
>> > > if(_includedProperties == null)
>> > > {
>> > > List<IncludePropertyNode> list = Collections.emptyList();
>> > > return list.iterator();
>> > > }
>> > > else
>> > > return (Arrays.asList(_includedProperties)).iterator();
>> > > }
>> > >
>> > > /**
>> > > * Gets the properties specified by this node's parent that should
>> be
>> > > * ignored. This method will return an empty iterator if
>> > > * {@link #isInhibitingAll()} returns <code>true</code>
>> > > *
>> > > * @return an iterator over the properties that should be ignored,
>> an
>> > > * empty iterator if all properties should be.
>> > > */
>> > > public Iterator<String> getInhibitedProperties()
>> > > {
>> > > if(_inhibitedProperties == null)
>> > > {
>> > > List<String> list = Collections.emptyList();
>> > > return list.iterator();
>> > > }
>> > > else
>> > > {
>> > > return _inhibitedProperties.iterator();
>> > > }
>> > > }
>> > >
>> >
>>
>>
>> --
>> Matthias Wessendorf
>> http://tinyurl.com/fmywh
>>
>> further stuff:
>> blog: http://jroller.com/page/mwessendorf
>> mail: mwessendorf-at-gmail-dot-com
>>
>
Re: return an Iterator vs a List
Posted by Simon Lessard <si...@gmail.com>.
In that specific case Iterable would be nice yeah.
On 4/5/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
> +1
>
> On 4/5/07, Adam Winer <aw...@gmail.com> wrote:()
> > If the only reason is to enable the fun new "for" syntax,
> > then we should change the type from Iterator to Iterable,
> > instead of List. List is a much larger contract.
> >
> > -- Adam
> >
> >
> > On 3/28/07, Jeanne Waldman <je...@oracle.com> wrote:
> > > Hi there,
> > > I'm in the Skinning StyleNode code and I see that the 'get' methods
> > > return Iterators
> > > from the good ol' days.
> > > It seems to me that it is better if they just return Lists so the code
> > > that iterates over
> > > the values is cleaner using 5.0's for(String foo : yyy) construct.
> > > Does anyone see why I wouldn't want these to return List instead of
> > > Iterator?
> > >
> > > Here's a code snippet. Thanks, Jeanne
> > > --
> > >
> > > public Iterator<IncludePropertyNode> getIncludedProperties()
> > > {
> > > if(_includedProperties == null)
> > > {
> > > List<IncludePropertyNode> list = Collections.emptyList();
> > > return list.iterator();
> > > }
> > > else
> > > return (Arrays.asList(_includedProperties)).iterator();
> > > }
> > >
> > > /**
> > > * Gets the properties specified by this node's parent that should
> be
> > > * ignored. This method will return an empty iterator if
> > > * {@link #isInhibitingAll()} returns <code>true</code>
> > > *
> > > * @return an iterator over the properties that should be ignored,
> an
> > > * empty iterator if all properties should be.
> > > */
> > > public Iterator<String> getInhibitedProperties()
> > > {
> > > if(_inhibitedProperties == null)
> > > {
> > > List<String> list = Collections.emptyList();
> > > return list.iterator();
> > > }
> > > else
> > > {
> > > return _inhibitedProperties.iterator();
> > > }
> > > }
> > >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: return an Iterator vs a List
Posted by Matthias Wessendorf <ma...@apache.org>.
+1
On 4/5/07, Adam Winer <aw...@gmail.com> wrote:
> If the only reason is to enable the fun new "for" syntax,
> then we should change the type from Iterator to Iterable,
> instead of List. List is a much larger contract.
>
> -- Adam
>
>
> On 3/28/07, Jeanne Waldman <je...@oracle.com> wrote:
> > Hi there,
> > I'm in the Skinning StyleNode code and I see that the 'get' methods
> > return Iterators
> > from the good ol' days.
> > It seems to me that it is better if they just return Lists so the code
> > that iterates over
> > the values is cleaner using 5.0's for(String foo : yyy) construct.
> > Does anyone see why I wouldn't want these to return List instead of
> > Iterator?
> >
> > Here's a code snippet. Thanks, Jeanne
> > --
> >
> > public Iterator<IncludePropertyNode> getIncludedProperties()
> > {
> > if(_includedProperties == null)
> > {
> > List<IncludePropertyNode> list = Collections.emptyList();
> > return list.iterator();
> > }
> > else
> > return (Arrays.asList(_includedProperties)).iterator();
> > }
> >
> > /**
> > * Gets the properties specified by this node's parent that should be
> > * ignored. This method will return an empty iterator if
> > * {@link #isInhibitingAll()} returns <code>true</code>
> > *
> > * @return an iterator over the properties that should be ignored, an
> > * empty iterator if all properties should be.
> > */
> > public Iterator<String> getInhibitedProperties()
> > {
> > if(_inhibitedProperties == null)
> > {
> > List<String> list = Collections.emptyList();
> > return list.iterator();
> > }
> > else
> > {
> > return _inhibitedProperties.iterator();
> > }
> > }
> >
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com