about making magritte more flexible... and founding the case for L17N

Hi,
This is a "disgression" of something I thought/implement last week and
I want to put into consideration, in order to know if is a valuable
contribution or just another stupid idea :)

First let mu put some context information: I'm using magritte for some
production applications, who has two major requirements: L&F and L17N.
For major of my needs, magritte fits quite well, but it still have some
restrictions:
1) No L17N in labels and buttons.
2) Buttons are texts and usually clients ask for images, images/texts, etc.

There are some other restrictions, but achievable by simply extending
magritte system (such as image report columns, etc.)

How do I solved this problems?
Well, first I simply added a "localized" method on String who asks for
a property (language) in session and follow "translated" path to
translate the string, and then I modified each method in magritte who
outputs a label (they are not many, just 3 or 4).
That solves my L17N problem.

Now, I want to make my buttons more fashionable... this is harder
because of the places where I have to change things... but again,
extending MAFormDecoration and MACommandColumn... and aplying that to
every component who uses a report... problem solved.
But, what if I what my buttons different, or even configurable?
This is my approach: instead having buttons and links displayed in
columns or forms, I created a Command, and then I whant to add that
commands by visiting different renderers, magritte style visitors. So,
if I want to change the displaying style, I just add a new renderer...
And as an "extra bonus" there I can handle L17N stuff.

What do you think? is this good approach?






_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> Well, first I simply added a "localized" method on String who asks for
> a property (language) in session and follow "translated" path to
> translate the string, and then I modified each method in magritte who
> outputs a label (they are not many, just 3 or 4).
> That solves my L17N problem.

I wrote a couple of applications using Magritte in multi-lingual  
environments. In Switzerland there are 4 official languages (German,  
French, Italian, and Rhaeto-Romanic). English is quite prominent too.

What we did at that time was to create our own String class,  
TranslatedString that responds to the same messages as String  
dispatches to the correct translation in the given context. This is  
similar to your approach, but does not require a change in Magritte.

> But, what if I what my buttons different, or even configurable?

Why not create your own MAFormDecoration (as a subclass or as your own  
Seaside decoration)? I mean, you can add any Seaside decoration around  
Magritte Forms and build something that exactly suits your needs. If  
this turns out to be a better and easier to customize than the one  
currently coming with Magritte, I might be interested to include in  
the core.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki