Re: Localization, Bookmarkable pages, and mounting strategies
Haha, brilliant. Sometimes you forget the simple stuff :) Thanks Sebastiaan, Erik. Sebastiaan van Erk wrote: > Shouldn't it work if you just override getLocale() on your admin base > page to return your admin locale? > > Regards, > Sebastiaan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization, Bookmarkable pages, and mounting strategies
Erik van Oosten wrote: Johan Compagner wrote: So then we should give a Page a locale field. I am in favour of doing this, even if Sebastiaan's problem is solved differently. I have a part of my site that is multilingual (the public pages), and another part is not (the admin screens, in English). Unfortunately when the locale is say Dutch, a lot of default Wicket texts are in Dutch while the rest of the page is in English. Regards, Erik. Shouldn't it work if you just override getLocale() on your admin base page to return your admin locale? Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
Johan Compagner wrote: > So then we should give a Page a locale field. I am in favour of doing this, even if Sebastiaan's problem is solved differently. I have a part of my site that is multilingual (the public pages), and another part is not (the admin screens, in English). Unfortunately when the locale is say Dutch, a lot of default Wicket texts are in Dutch while the rest of the page is in English. Regards, Erik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization, Bookmarkable pages, and mounting strategies
Johan Compagner wrote:
The problem is that a component has not a locale by default
So then we should give a Page a locale field.
and then that will be set..
But the problem is
if you do setResponsePage(Page.class)
what should then be taken? The session locale mount?
The most logical thing to me seems to be the result of getLocale(), because:
1) if the locale in the page is explicitly set, that means you're
browsing the site explicitly in the selected locale... This seems
logical to me: if you reqeuest the english version of a page through a
bookmarkable link, then it would be weird if the next page you go to is
suddenly in German, even if your session locale is German...
2) if it is not explicitly the session locale should be used...
Regards,
Sebastiaan
johan
On Mon, Apr 14, 2008 at 6:14 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
wrote:
Johan Compagner wrote:
So when you do this:
mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class,
Locale.NL));
then when i hit
/mypage
we have to set the sessions locale to NL then?
I don't think so. The *resource* has the specified locale, i.e., the Page,
but I think it's bad to have as side effect that the session's locale is
suddenly changed.
I realize this introduces other issues... what happens with a Link to
another page class? It should use the Page locale, not the session locale...
So a component uses its locale, or its parent locale, or its parent's
parent, etc, and if Page doesn't have a locale, THEN the session locale...
But I don't know the inner workings of Wicket's localization, nor have I
thought long and hard about this yet, so I don't know if any of this make
sense...
I just think it's weird that I cannot mount 2 locales of a page on two
different paths... leading to the crawler and reference issues I mentioned
before... What the best solution is, is probably something that needs to be
discussed further. :-)
Regards,
Sebastiaan
Regards,
Sebastiaan
johan
On Mon, Apr 14, 2008 at 12:40 PM, Sebastiaan van Erk <
[EMAIL PROTECTED]>
wrote:
Hi,
I have localized my Wicket site, but I have a problem with
localization +
(mounted) bookmarkable pages.
When mounting a bookmarkable page:
mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class));
there is no locale parameter...
This means:
1) I cannot give my stateless pages of different locales different
URLs,
which means that nobody can link directly to a non-default locale
version of
the page.
2) My stateless pages are impossible to index in different locales.
Google
either finds only the default locale pages, or must follow a stateful
"change locale" link, which will cause it to index pages which will be
expired by the time they're in Google's search results.
I know that I can make my own workaround, i.e., write my own url
coding
strategy with the locale in the root, /en/mypage to the english
version,
/mypage to the default locale, etc.. Or I could use
IndexedParameterCodingStrategy to make the first parameter the locale
(although this does not work if I want to use another coding
strategy).
However they're still workarounds for something that I think is
conceptually not quite right in Wicket currently: the fact that it
should be
possible to mount different locales of a page on different urls, for
*whatever* coding strategy I choose to use.
Any ideas on this? Anybody already implemented the coding strategy for
the
locale in the root? Anybody got another easier workaround?
Regards,
Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
The problem is that a component has not a locale by default
So then we should give a Page a locale field.
and then that will be set..
But the problem is
if you do setResponsePage(Page.class)
what should then be taken? The session locale mount?
johan
On Mon, Apr 14, 2008 at 6:14 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
wrote:
> Johan Compagner wrote:
>
> > So when you do this:
> >
> > mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class,
> > Locale.NL));
> >
> > then when i hit
> >
> > /mypage
> >
> > we have to set the sessions locale to NL then?
> >
>
> I don't think so. The *resource* has the specified locale, i.e., the Page,
> but I think it's bad to have as side effect that the session's locale is
> suddenly changed.
>
> I realize this introduces other issues... what happens with a Link to
> another page class? It should use the Page locale, not the session locale...
> So a component uses its locale, or its parent locale, or its parent's
> parent, etc, and if Page doesn't have a locale, THEN the session locale...
>
> But I don't know the inner workings of Wicket's localization, nor have I
> thought long and hard about this yet, so I don't know if any of this make
> sense...
>
> I just think it's weird that I cannot mount 2 locales of a page on two
> different paths... leading to the crawler and reference issues I mentioned
> before... What the best solution is, is probably something that needs to be
> discussed further. :-)
>
> Regards,
> Sebastiaan
>
>
>
> Regards,
> Sebastiaan
>
>
> johan
> >
> >
> > On Mon, Apr 14, 2008 at 12:40 PM, Sebastiaan van Erk <
> > [EMAIL PROTECTED]>
> > wrote:
> >
> > Hi,
> > >
> > > I have localized my Wicket site, but I have a problem with
> > > localization +
> > > (mounted) bookmarkable pages.
> > >
> > > When mounting a bookmarkable page:
> > >
> > > mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class));
> > >
> > > there is no locale parameter...
> > >
> > > This means:
> > >
> > > 1) I cannot give my stateless pages of different locales different
> > > URLs,
> > > which means that nobody can link directly to a non-default locale
> > > version of
> > > the page.
> > >
> > > 2) My stateless pages are impossible to index in different locales.
> > > Google
> > > either finds only the default locale pages, or must follow a stateful
> > > "change locale" link, which will cause it to index pages which will be
> > > expired by the time they're in Google's search results.
> > >
> > > I know that I can make my own workaround, i.e., write my own url
> > > coding
> > > strategy with the locale in the root, /en/mypage to the english
> > > version,
> > > /mypage to the default locale, etc.. Or I could use
> > > IndexedParameterCodingStrategy to make the first parameter the locale
> > > (although this does not work if I want to use another coding
> > > strategy).
> > >
> > > However they're still workarounds for something that I think is
> > > conceptually not quite right in Wicket currently: the fact that it
> > > should be
> > > possible to mount different locales of a page on different urls, for
> > > *whatever* coding strategy I choose to use.
> > >
> > > Any ideas on this? Anybody already implemented the coding strategy for
> > > the
> > > locale in the root? Anybody got another easier workaround?
> > >
> > > Regards,
> > > Sebastiaan
> > >
> > >
> > >
> >
Re: Localization, Bookmarkable pages, and mounting strategies
hi sebastiaan, Btw: do you have a change locale link? How do you make sure it plays nice with bookmarkable urls? actually, since the locale is filtered out from the actual url - you don't have to worry about this at all. just link the user to the /de/xy or /en/xy-pages and you get called the xy-mount with the right locale... best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization, Bookmarkable pages, and mounting strategies
Nope, no questions, readable enough. I'll give it a shot in my
application Thanks a lot!
Btw: do you have a change locale link? How do you make sure it plays
nice with bookmarkable urls? I was thinking of using a redirect if the
page is bookmarkable, but haven't worked it out yet...
Thanks again,
Sebastiaan
Jan Kriesten wrote:
hi sebastiaan,
i just snip the things out and comment (as far as necessary):
use this filter instead of the default wicket filter:
---8<---
object LocaleFilter
{
final val REQUEST_LOCALE_ATTRIBUTE = "_request_locale_"
}
class LocaleFilter extends WicketFilter
{
import de.footprint.utils.lang.LocaleUtils
import javax.servlet.http.HttpServletRequest
/**
* Extracts an optional locale attribute from the request path and
sets the
* requests locale as an request attribute. The part of the request
path before
* the first '/' is checked against available java system locales.
*
* @param request
* incoming request
* @return relative request paths w/o locale attribute
*/
override def getRelativePath( request: HttpServletRequest ) =
{
val relPath = super.getRelativePath( request )
val len = relPath.length
val idx = if( len>2 ) relPath.indexOf( '/' ) else -1
if( idx >= 0 )
{
val lang = relPath.substring( 0, idx )
LocaleUtils.getLocale( lang ) match
{
case Some(locale) =>
request.setAttribute( LocaleFilter.REQUEST_LOCALE_ATTRIBUTE,
locale )
if( len > lang.length ) relPath.substring( lang.length + 1 )
else ""
case _ => relPath
}
}
else relPath
}
}
---8<---
i think that's self explanatory.
second, you have to alter application, session + request a bit.
Application:
---8<---
abstract class LocaleApplication extends WebApplication
{
/**
* Evaluate the current Locale to use.
*
* Based on the Locale provided by the LocaleFilter, the current
Locale is selected as:
*
* - if none is set and no Locale is passed in, the Application
default Locale is returned
* - if none is set but a Locale is passed in, this is returned
* - if a Locale is set by the filter and this is supported by the
Application, its returned
* - if a Locale is set but unsupported, the default Locale is returned
*
* @param currentLocale
* current Locale in use or null
* @return Locale to use
*/
protected[application] def getLocale( currentLocale: Locale ) : Locale =
{
val request =
RequestCycle.get.getRequest.asInstanceOf[WebRequest].getHttpServletRequest.asInstanceOf[HttpServletRequest];
val requestLocale = request.getAttribute(
LocaleFilter.REQUEST_LOCALE_ATTRIBUTE ).asInstanceOf[Locale];
if( requestLocale == null )
{
if( currentLocale == null ) getDefaultLocale
else currentLocale
}
else
if( currentLocale == null || currentLocale != requestLocale )
{
getSupportedLocales.find( x => x == requestLocale || x.getLanguage
== requestLocale.getLanguage ).getOrElse( getDefaultLocale )
}
else currentLocale
}
/**
* Sets the Locale to use in newly created sessions.
*
* @param session
* newly created session
*/
protected def sessionCreateListener( session: WebSession ) =
session.setLocale( getLocale( null ) )
/**
* Overridden to use the unified Locale selection
*
* @param servletRequest
* Current request to generate Request instance for.
* @return new LocaleRequest instance
*/
override protected def newWebRequest( servletRequest:
HttpServletRequest ) = new LocaleRequest( servletRequest )
}
---8<---
Request:
---8<---
class LocaleRequest( req: HttpServletRequest ) extends UploadWebRequest(
req )
{
override def getLocale = LocaleApplication.get.getLocale( null )
}
---8<---
Session:
---8<---
class LocaleSession( req: Request ) extends WebSession( req )
{
override def getLocale =
{
val sessionLocale = super.getLocale
val requestLocale = LocaleApplication.get.getLocale( sessionLocale )
if( sessionLocale!=requestLocale )
setLocale( requestLocale )
requestLocale
}
}
---8<---
any questions? :D
best regards, --- jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
hi sebastiaan,
i just snip the things out and comment (as far as necessary):
use this filter instead of the default wicket filter:
---8<---
object LocaleFilter
{
final val REQUEST_LOCALE_ATTRIBUTE = "_request_locale_"
}
class LocaleFilter extends WicketFilter
{
import de.footprint.utils.lang.LocaleUtils
import javax.servlet.http.HttpServletRequest
/**
* Extracts an optional locale attribute from the request path and sets the
* requests locale as an request attribute. The part of the request path
before
* the first '/' is checked against available java system locales.
*
* @param request
* incoming request
* @return relative request paths w/o locale attribute
*/
override def getRelativePath( request: HttpServletRequest ) =
{
val relPath = super.getRelativePath( request )
val len = relPath.length
val idx = if( len>2 ) relPath.indexOf( '/' ) else -1
if( idx >= 0 )
{
val lang = relPath.substring( 0, idx )
LocaleUtils.getLocale( lang ) match
{
case Some(locale) =>
request.setAttribute( LocaleFilter.REQUEST_LOCALE_ATTRIBUTE, locale )
if( len > lang.length ) relPath.substring( lang.length + 1 )
else ""
case _ => relPath
}
}
else relPath
}
}
---8<---
i think that's self explanatory.
second, you have to alter application, session + request a bit.
Application:
---8<---
abstract class LocaleApplication extends WebApplication
{
/**
* Evaluate the current Locale to use.
*
* Based on the Locale provided by the LocaleFilter, the current Locale is
selected as:
*
* - if none is set and no Locale is passed in, the Application default
Locale is returned
* - if none is set but a Locale is passed in, this is returned
* - if a Locale is set by the filter and this is supported by the
Application, its returned
* - if a Locale is set but unsupported, the default Locale is returned
*
* @param currentLocale
* current Locale in use or null
* @return Locale to use
*/
protected[application] def getLocale( currentLocale: Locale ) : Locale =
{
val request =
RequestCycle.get.getRequest.asInstanceOf[WebRequest].getHttpServletRequest.asInstanceOf[HttpServletRequest];
val requestLocale = request.getAttribute(
LocaleFilter.REQUEST_LOCALE_ATTRIBUTE ).asInstanceOf[Locale];
if( requestLocale == null )
{
if( currentLocale == null ) getDefaultLocale
else currentLocale
}
else
if( currentLocale == null || currentLocale != requestLocale )
{
getSupportedLocales.find( x => x == requestLocale || x.getLanguage ==
requestLocale.getLanguage ).getOrElse( getDefaultLocale )
}
else currentLocale
}
/**
* Sets the Locale to use in newly created sessions.
*
* @param session
* newly created session
*/
protected def sessionCreateListener( session: WebSession ) =
session.setLocale( getLocale( null ) )
/**
* Overridden to use the unified Locale selection
*
* @param servletRequest
* Current request to generate Request instance for.
* @return new LocaleRequest instance
*/
override protected def newWebRequest( servletRequest: HttpServletRequest ) =
new LocaleRequest( servletRequest )
}
---8<---
Request:
---8<---
class LocaleRequest( req: HttpServletRequest ) extends UploadWebRequest( req )
{
override def getLocale = LocaleApplication.get.getLocale( null )
}
---8<---
Session:
---8<---
class LocaleSession( req: Request ) extends WebSession( req )
{
override def getLocale =
{
val sessionLocale = super.getLocale
val requestLocale = LocaleApplication.get.getLocale( sessionLocale )
if( sessionLocale!=requestLocale )
setLocale( requestLocale )
requestLocale
}
}
---8<---
any questions? :D
best regards, --- jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization, Bookmarkable pages, and mounting strategies
Hmm.. Scala :-) I guess I'll opt for English then :-) I don't quite understand what you do... taking it out of the filter is easy enough I guess, but then? When you set a property on the application how does this work with different threads? Do you use thread local? Then you do you render the selected page in the specified locale? Regards, Sebastiaan Jan Kriesten wrote: hi sebastiaan, Would you be willing to share that code? Because in the short term I think it's the best solution. it's all Scala - if you want that... ;-) best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
Johan Compagner wrote:
So when you do this:
mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class, Locale.NL));
then when i hit
/mypage
we have to set the sessions locale to NL then?
I don't think so. The *resource* has the specified locale, i.e., the
Page, but I think it's bad to have as side effect that the session's
locale is suddenly changed.
I realize this introduces other issues... what happens with a Link to
another page class? It should use the Page locale, not the session
locale... So a component uses its locale, or its parent locale, or its
parent's parent, etc, and if Page doesn't have a locale, THEN the
session locale...
But I don't know the inner workings of Wicket's localization, nor have I
thought long and hard about this yet, so I don't know if any of this
make sense...
I just think it's weird that I cannot mount 2 locales of a page on two
different paths... leading to the crawler and reference issues I
mentioned before... What the best solution is, is probably something
that needs to be discussed further. :-)
Regards,
Sebastiaan
Regards,
Sebastiaan
johan
On Mon, Apr 14, 2008 at 12:40 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
wrote:
Hi,
I have localized my Wicket site, but I have a problem with localization +
(mounted) bookmarkable pages.
When mounting a bookmarkable page:
mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class));
there is no locale parameter...
This means:
1) I cannot give my stateless pages of different locales different URLs,
which means that nobody can link directly to a non-default locale version of
the page.
2) My stateless pages are impossible to index in different locales. Google
either finds only the default locale pages, or must follow a stateful
"change locale" link, which will cause it to index pages which will be
expired by the time they're in Google's search results.
I know that I can make my own workaround, i.e., write my own url coding
strategy with the locale in the root, /en/mypage to the english version,
/mypage to the default locale, etc.. Or I could use
IndexedParameterCodingStrategy to make the first parameter the locale
(although this does not work if I want to use another coding strategy).
However they're still workarounds for something that I think is
conceptually not quite right in Wicket currently: the fact that it should be
possible to mount different locales of a page on different urls, for
*whatever* coding strategy I choose to use.
Any ideas on this? Anybody already implemented the coding strategy for the
locale in the root? Anybody got another easier workaround?
Regards,
Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
hi sebastiaan, Would you be willing to share that code? Because in the short term I think it's the best solution. it's all Scala - if you want that... ;-) best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization, Bookmarkable pages, and mounting strategies
Hi Jan, Would you be willing to share that code? Because in the short term I think it's the best solution. Regards, Sebastiaan Jan Kriesten wrote: hi sebastiaan, Any ideas on this? Anybody already implemented the coding strategy for the locale in the root? Anybody got another easier workaround? i don't use a coding strategy for this but an extension to wicket filter that parses the 'relative path' of the url for locale definitions, strips them and sets a locale-attribute to the application. e.g.: http://my.host.de/app/en/mymount/ --> /mymount/ with locale 'en' http://my.host.de/app/pt/mymount/ --> /mymount/ with locale 'pt' best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
hi sebastiaan, Any ideas on this? Anybody already implemented the coding strategy for the locale in the root? Anybody got another easier workaround? i don't use a coding strategy for this but an extension to wicket filter that parses the 'relative path' of the url for locale definitions, strips them and sets a locale-attribute to the application. e.g.: http://my.host.de/app/en/mymount/ --> /mymount/ with locale 'en' http://my.host.de/app/pt/mymount/ --> /mymount/ with locale 'pt' best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization, Bookmarkable pages, and mounting strategies
So when you do this:
mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class, Locale.NL));
then when i hit
/mypage
we have to set the sessions locale to NL then?
johan
On Mon, Apr 14, 2008 at 12:40 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I have localized my Wicket site, but I have a problem with localization +
> (mounted) bookmarkable pages.
>
> When mounting a bookmarkable page:
>
>mount(new WhateverUrlCodingStrategy("/mypage", MyPage.class));
>
> there is no locale parameter...
>
> This means:
>
> 1) I cannot give my stateless pages of different locales different URLs,
> which means that nobody can link directly to a non-default locale version of
> the page.
>
> 2) My stateless pages are impossible to index in different locales. Google
> either finds only the default locale pages, or must follow a stateful
> "change locale" link, which will cause it to index pages which will be
> expired by the time they're in Google's search results.
>
> I know that I can make my own workaround, i.e., write my own url coding
> strategy with the locale in the root, /en/mypage to the english version,
> /mypage to the default locale, etc.. Or I could use
> IndexedParameterCodingStrategy to make the first parameter the locale
> (although this does not work if I want to use another coding strategy).
>
> However they're still workarounds for something that I think is
> conceptually not quite right in Wicket currently: the fact that it should be
> possible to mount different locales of a page on different urls, for
> *whatever* coding strategy I choose to use.
>
> Any ideas on this? Anybody already implemented the coding strategy for the
> locale in the root? Anybody got another easier workaround?
>
> Regards,
> Sebastiaan
>
>
Re: Localization, Bookmarkable pages, and mounting strategies
Gwyn Evans wrote: On Mon, Apr 14, 2008 at 11:40 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: However they're still workarounds for something that I think is conceptually not quite right in Wicket currently: the fact that it should be possible to mount different locales of a page on different urls, for *whatever* coding strategy I choose to use. I suspect that it's just that the default behaviour (automatically using the user's locale to return the locale-specific page) covers the majority of requirements & no-one's raised an issue to modify the url coding strategies, let alone contributed code! A quick search back on the list suggested something similar had been asked by various people a couple of times before, but it's not clear if anything was then coded or if they found a different approach. Yes, I did the search as well, and saw nobody with a clear answer on how they went about it. The best approach I saw on the list was getting the locale from the root part of the URL, but I'm not that deep into wicket that I'd know how to go about building that in a proper way. Note that even if you think you can't contribute code for one reason or another, an discussion here followed by a JIRA issue with specific use-cases will mean it's not forgotten, at least. It does seem unlogical to me that you would *mount* different versions of a resource on a single URL, so I'll open a JIRA on it. /Gwyn smime.p7s Description: S/MIME Cryptographic Signature
Re: Localization, Bookmarkable pages, and mounting strategies
On Mon, Apr 14, 2008 at 11:40 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > However they're still workarounds for something that I think is > conceptually not quite right in Wicket currently: the fact that it should be > possible to mount different locales of a page on different urls, for > *whatever* coding strategy I choose to use. I suspect that it's just that the default behaviour (automatically using the user's locale to return the locale-specific page) covers the majority of requirements & no-one's raised an issue to modify the url coding strategies, let alone contributed code! A quick search back on the list suggested something similar had been asked by various people a couple of times before, but it's not clear if anything was then coded or if they found a different approach. Note that even if you think you can't contribute code for one reason or another, an discussion here followed by a JIRA issue with specific use-cases will mean it's not forgotten, at least. /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
