MapperRules.nameToDisplayName?
Jeppe Nejsum Madsen
In the interest of cutting boilerplate from mapped objects, I would
like to get the display name from a property file.
So I was thinking that it would be an idea to add a
MapperRules.nameToDisplayName such as this
var nameToDisplayName: ( Mapper[_], String) = (_,name) => name
This would allow me to do things like nameToDisplayName = (m,name) =>
S.?(m.getClass.getName+"."+name)
Thoughts?
/Jeppe
Jim Barrows
Hi,
In the interest of cutting boilerplate from mapped objects, I would
like to get the display name from a property file.
So your replacing code boilerplate with property file boilerplate? The boilerplate has to go somewhere, and abstracting things like this out doesn't change that. On the other hand, if you have to l10n your app, then this works.
What about turning it off by default, and turned on in Boot though. Also it should probably use the existing method by default, rolling to the property file if it's turned on and it's not provided.
So I was thinking that it would be an idea to add a
MapperRules.nameToDisplayName such as this
var nameToDisplayName: ( Mapper[_], String) = (_,name) => name
A department of redundancy department approved name? :) *LOL*
How about displayNameFromPropertyFile? A little wordy, but it shouldn't ever need to be typed except to be overridden.
This would allow me to do things like nameToDisplayName = (m,name) =>
S.?(m.getClass.getName+"."+name)
Thoughts?
/Jeppe
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
James A Barrows
David Pollak
On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:Hi,
In the interest of cutting boilerplate from mapped objects, I would
like to get the display name from a property file.
So your replacing code boilerplate with property file boilerplate? The boilerplate has to go somewhere, and abstracting things like this out doesn't change that. On the other hand, if you have to l10n your app, then this works.
What about turning it off by default, and turned on in Boot though. Also it should probably use the existing method by default, rolling to the property file if it's turned on and it's not provided.
Yeah... I gotta say, the less stuff that winds up outside Scala by default, the better.
So I was thinking that it would be an idea to add a
MapperRules.nameToDisplayName such as this
var nameToDisplayName: ( Mapper[_], String) = (_,name) => name
A department of redundancy department approved name? :) *LOL*
How about displayNameFromPropertyFile? A little wordy, but it shouldn't ever need to be typed except to be overridden.
This would allow me to do things like nameToDisplayName = (m,name) =>
S.?(m.getClass.getName+"."+name)
Thoughts?
/Jeppe
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
James A Barrows
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Jeppe Nejsum Madsen
> On Mon, Mar 1, 2010 at 8:27 AM, Jim Barrows <jim.b...@gmail.com> wrote:
>
>>
>> On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>>
>>> Hi,
>>>
>>> In the interest of cutting boilerplate from mapped objects, I would
>>> like to get the display name from a property file.
>>>
>>
>> So your replacing code boilerplate with property file boilerplate? The
>> boilerplate has to go somewhere, and abstracting things like this out
>> doesn't change that. On the other hand, if you have to l10n your app, then
>> this works.
>>
>> What about turning it off by default, and turned on in Boot though. Also
>> it should probably use the existing method by default, rolling to the
>> property file if it's turned on and it's not provided.
>>
>
> Yeah... I gotta say, the less stuff that winds up outside Scala by default,
> the better.
Well, you probably have the luxury of not having to localize your
apps. Unfortunately, I don't :-(
But I'm interested if you know of better ways to handle i18n for things
like displayName.
/Jeppe
Jeppe Nejsum Madsen
> On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>
>> Hi,
>>
>> In the interest of cutting boilerplate from mapped objects, I would
>> like to get the display name from a property file.
>>
>
> So your replacing code boilerplate with property file boilerplate? The
> boilerplate has to go somewhere, and abstracting things like this out
> doesn't change that.
Yes it does. Now I have to go through all my 100+ fields and add:
override def displayName = S.?(getClass.getName+"."+name)
Same line in every field. That counts as boilerplate for me :-)
> On the other hand, if you have to l10n your app, then this works.
Exactly.
> What about turning it off by default, and turned on in Boot though. Also it
> should probably use the existing method by default, rolling to the property
> file if it's turned on and it's not provided.
That was pretty much what I suggested.....except I don't want to force
people to use displayNameFromPropertyFile. They could provide their own
function that looked it up in a db, generated random names etc.
/Jeppe
Jim Barrows
Jim Barrows <jim.b...@gmail.com> writes:Yes it does. Now I have to go through all my 100+ fields and add:
> On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>
>> Hi,
>>
>> In the interest of cutting boilerplate from mapped objects, I would
>> like to get the display name from a property file.
>>
>
> So your replacing code boilerplate with property file boilerplate? The
> boilerplate has to go somewhere, and abstracting things like this out
> doesn't change that.
override def displayName = S.?(getClass.getName+"."+name)
My point was that you've moved the boilerplate, not eliminated it. If what you suggest was in place you'd have to add 100+ properties in a file.
Same line in every field. That counts as boilerplate for me :-)
Exactly.
> On the other hand, if you have to l10n your app, then this works.
That was pretty much what I suggested.....except I don't want to force
> What about turning it off by default, and turned on in Boot though. Also it
> should probably use the existing method by default, rolling to the property
> file if it's turned on and it's not provided.
people to use displayNameFromPropertyFile. They could provide their own
function that looked it up in a db, generated random names etc.
Okay, so displayNameFactory maybe?
/Jeppe
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
James A Barrows
Jeppe Nejsum Madsen
> My point was that you've moved the boilerplate, not eliminated it. If what
> you suggest was in place you'd have to add 100+ properties in a file.
I'm not sure if we're wandering out on a philosophical tangent here, but
would genuinely like to hear if you have better solutions:
Given that I have say 100 fields and need it translated to say 5
different languages.
I need to have at least 500 words stored somewhere. If I don't want to
use a word's position in the file as key, I'll need a key per word. I
would also like one file per language since this allows independent
translation. So now I have 5 files each with 100 lines containing two
words.
But AFAIKS, there's no repetition (except for the keys, which I think
are unavoidable), so no boilerplate.
Now I have to add the 100 overrides to actually look up the translated
names. This is the only place I see boilerplate, and it could be easily
removed :-)
I agree 100% that if you don't need translation, properties are often
the wrong approach, but when you do need it I've yet to see a better
alternative (but would love to hear about it!)
/Jeppe
David Pollak
display name calculator: (Mapper[_], Locale, String) => Box[String] // we could use Lift's factory mechanism here
Then you have lots of room to keep the current implementation as the default if there is no actual name calculated. Further, the calculation is not based on the currently logged in user, so you could cache the results (or not if you're in development mode).
My issue is that I like to not push functions like this towards external files, but allow external files (and other resources) to be consulted depending on the localization mechanism chosen for the given project.
/Jeppe
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Jeppe Nejsum Madsen
> If the mechanism was something more along the lines of:
>
> display name calculator: (Mapper[_], Locale, String) => Box[String] // we
> could use Lift's factory mechanism here
I'm completely blank as to the factory mechanism, but this might be a
good excuse to get started :-) Do you mean something like this in
MapperRules:
val displayNameCalculator: FactoryMaker[(Mapper[_], Locale, String) =>
Box[String]] = new FactoryMaker((_,_,_) => Empty) {}
Is there a need for the Boxed return type? Seems cleaner to just return
the passed name. But either is fine with me :-)
> Then you have lots of room to keep the current implementation as the default
> if there is no actual name calculated. Further, the calculation is not
> based on the currently logged in user, so you could cache the results (or
> not if you're in development mode).
I assume in the implementation that Mapper would have to use S.locale to
supply the locale? Or should this also be abstracted?
> My issue is that I like to not push functions like this towards external
> files, but allow external files (and other resources) to be consulted
> depending on the localization mechanism chosen for the given project.
Not sure I understand this correctly (probably a language thing :-) Do
you mean that you don't like to have this hard coded to e.g. S.?() or
more that the config hooks should provide enough parameters that you're
free to choose something other than S.?()
I think my original proposal solved the former, but probably (due to
lack of locale) not the latter.
/Jeppe
David Pollak
> If the mechanism was something more along the lines of:I'm completely blank as to the factory mechanism, but this might be a
>
> display name calculator: (Mapper[_], Locale, String) => Box[String] // we
> could use Lift's factory mechanism here
good excuse to get started :-) Do you mean something like this in
MapperRules:
val displayNameCalculator: FactoryMaker[(Mapper[_], Locale, String) =>
Box[String]] = new FactoryMaker((_,_,_) => Empty) {}
Yeah.
Is there a need for the Boxed return type? Seems cleaner to just return
the passed name. But either is fine with me :-)
I assume in the implementation that Mapper would have to use S.locale to
> Then you have lots of room to keep the current implementation as the default
> if there is no actual name calculated. Further, the calculation is not
> based on the currently logged in user, so you could cache the results (or
> not if you're in development mode).
supply the locale? Or should this also be abstracted?
S.locale is just fine.
Not sure I understand this correctly (probably a language thing :-) Do
> My issue is that I like to not push functions like this towards external
> files, but allow external files (and other resources) to be consulted
> depending on the localization mechanism chosen for the given project.
you mean that you don't like to have this hard coded to e.g. S.?() or
more that the config hooks should provide enough parameters that you're
free to choose something other than S.?()
Both.
I think my original proposal solved the former, but probably (due to
lack of locale) not the latter.
/Jeppe
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.