Re: 1.4-dev, overriding Uberspect, would like Info class to conta in Context

[Victor Wiewiorowski <vw...@valuecommerce.ne.jp>]

Geir Magnusson Jr . wrote:

> I certainly see the need, but, well, yuck :)

Please try to not think of this as `yuck' but as doing something
very cool with velocity. If generalized I think it might become a powerful
idiom that many people could use.

> What I don't understand is why you don't deal with this at a higher level 
> - i.e. because it's a formatting issue, the designer making the template
knows 
> when they are showing the date, and thus can use a tool placed into the 
> context to format appropriate to that request.
>
> Does that make sense? 

The thing we love about velocity is the simplicity of the template code, 
simplicity for the template designer.

What you are suggesting would give templates like:

    $dateformater.format($user.SignUpDate) instead of just $user.SignUpDate

which is not something I want the template writer to have to
think of. Especially when it comes to language-specific enums,
I want to be able to say $user.AccountStatus and have the
string in the right language inserted,  instead of having to say
$accountStatusFormatter.format($user.AccountStatus),
or $formatter.format($user.AccountStatus) everywhere with 
some very scary code in the format method. 

I could achieve part of what I want with the EventCartridge, if, again,
the referenceInsert method knew what context the reference was coming
from. However that would not work for advanced formatting, where I want a
DateBean
wrapping all Dates that has methods on it, say getDayOfWeek()

If this change to the Info class would be considered for 1.4 I will gladly
write it 
and submit a patch.

Regards,

Victor Wiewiorowski
ValueCommerce Co., Ltd.

 On Wednesday, April 2, 2003, at 01:09 AM, Victor Wiewiorowski wrote:

>> I am working on a multi-lingual web-application, I would like to display
>> dates (for example) in a format specific to the locale the application
user
>> has requested. As this is a web-app serving multiple users, the
>> JVM Locale is of no use to me.
>> 
>> I was thinking that it would be nice if I could do this transparently,
that
>> is within velocity whenever a Date is returned wrap it in a DateBean
>> which is constructed with the locale and displays the date appropriately.
>> 
>> I can *almost* do this in velocity-1.4-dev by writing my own
>> Uberspect which wraps the default UberspectImpl returning a wrapper
>> class in getPropertyGet.
>> 
>> However when it comes to evaluation I have no way of knowing for
>> which context this evaluation is for, so I don't know what Locale the
>> Date should be displayed in.

>> I think what needs to be done is the Info class should include the
context
>> for which the evaluation is happening, this will make it possible to make
>> much more interesting Uberspect-s.



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: 1.4-dev, overriding Uberspect, would like Info class to conta in Context

[Ch...@dlr.de]

Hello Victor,

have you considered using your own context implementation, so when you
return a Date, it returns it wrapped. Then the toString() can do your
desired miracle.

Any method call to your wrapper apart from toString(), will return the
original method output. Possibly the wrapper can wrap it up again! If
the wrapper implements the map interface, you can take advantage of
the velocity introspection mechanism and get grip on the invocations.

I'm not quite sure if (at rendering time) the last method called on a
context object is toString().

Please send a note to the list if you did consider (or even impelmented)
this approach and it worked, or why it does not.

Cheers,
Christoph

Victor Wiewiorowski wrote:
> Geir Magnusson Jr . wrote:
> 
> 
>>I certainly see the need, but, well, yuck :)
> 
> 
> Please try to not think of this as `yuck' but as doing something
> very cool with velocity. If generalized I think it might become a powerful
> idiom that many people could use.
> 
> 
>>What I don't understand is why you don't deal with this at a higher level 
>>- i.e. because it's a formatting issue, the designer making the template
> 
> knows 
> 
>>when they are showing the date, and thus can use a tool placed into the 
>>context to format appropriate to that request.
>>
>>Does that make sense? 
> 
> 
> The thing we love about velocity is the simplicity of the template code, 
> simplicity for the template designer.
> 
> What you are suggesting would give templates like:
> 
>     $dateformater.format($user.SignUpDate) instead of just $user.SignUpDate
> 
> which is not something I want the template writer to have to
> think of. Especially when it comes to language-specific enums,
> I want to be able to say $user.AccountStatus and have the
> string in the right language inserted,  instead of having to say
> $accountStatusFormatter.format($user.AccountStatus),
> or $formatter.format($user.AccountStatus) everywhere with 
> some very scary code in the format method. 
> 
> I could achieve part of what I want with the EventCartridge, if, again,
> the referenceInsert method knew what context the reference was coming
> from. However that would not work for advanced formatting, where I want a
> DateBean
> wrapping all Dates that has methods on it, say getDayOfWeek()
> 
> If this change to the Info class would be considered for 1.4 I will gladly
> write it 
> and submit a patch.
> 
> Regards,
> 
> Victor Wiewiorowski
> ValueCommerce Co., Ltd.
> 
>  On Wednesday, April 2, 2003, at 01:09 AM, Victor Wiewiorowski wrote:
> 
> 
>>>I am working on a multi-lingual web-application, I would like to display
>>>dates (for example) in a format specific to the locale the application
> 
> user
> 
>>>has requested. As this is a web-app serving multiple users, the
>>>JVM Locale is of no use to me.
>>>
>>>I was thinking that it would be nice if I could do this transparently,
> 
> that
> 
>>>is within velocity whenever a Date is returned wrap it in a DateBean
>>>which is constructed with the locale and displays the date appropriately.
>>>
>>>I can *almost* do this in velocity-1.4-dev by writing my own
>>>Uberspect which wraps the default UberspectImpl returning a wrapper
>>>class in getPropertyGet.
>>>
>>>However when it comes to evaluation I have no way of knowing for
>>>which context this evaluation is for, so I don't know what Locale the
>>>Date should be displayed in.
> 
> 
>>>I think what needs to be done is the Info class should include the
> 
> context
> 
>>>for which the evaluation is happening, this will make it possible to make
>>>much more interesting Uberspect-s.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> 
> 

-- 
:) Christoph Reck


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: 1.4-dev, overriding Uberspect, would like Info class to contain Context

[Jon Scott Stevens <jo...@latchkey.com>]

on 2003/4/7 2:49 PM, "Attila Szegedi" <sz...@freemail.hu> wrote:

> To me, this looks as moving a concern of the view layer (namely, output
> formatting) into the model layer.
> 
> As a quick-and-dirty solution it surely works, but it is far from the
> approach template engines encourage, namely the clean separation of M and V
> concerns.
> 
> Just my 2c.
> Attila.

I agree with that as well (and Scarab is careful to wrap things in the view
layer as you suggest)...but what the guy *wanted* was something else. =)

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: 1.4-dev, overriding Uberspect, would like Info class to contain Context

[Attila Szegedi <sz...@freemail.hu>]

To me, this looks as moving a concern of the view layer (namely, output
formatting) into the model layer.

As a quick-and-dirty solution it surely works, but it is far from the
approach template engines encourage, namely the clean separation of M and V
concerns.

Just my 2c.
Attila.

----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: "velocity-dev" <ve...@jakarta.apache.org>
Sent: Monday, April 07, 2003 7:52 PM
Subject: Re: 1.4-dev, overriding Uberspect, would like Info class to contain
Context


> on 2003/4/7 1:55 AM, "Victor Wiewiorowski" <vw...@valuecommerce.ne.jp>
> wrote:
>
> > What you are suggesting would give templates like:
> >
> >   $dateformater.format($user.SignUpDate) instead of just
$user.SignUpDate
>
> If you are going to do that, then you might as well do this:
>
> public class User
> {
>     public String getSignUpDate()
>     {
>         return dateformatter.format(signUpDate);
>     }
> }
>
> Make sense?
>
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: 1.4-dev, overriding Uberspect, would like Info class to conta in Context

[Jon Scott Stevens <jo...@latchkey.com>]

on 2003/4/7 1:55 AM, "Victor Wiewiorowski" <vw...@valuecommerce.ne.jp>
wrote:

> What you are suggesting would give templates like:
> 
>   $dateformater.format($user.SignUpDate) instead of just $user.SignUpDate

If you are going to do that, then you might as well do this:

public class User
{
    public String getSignUpDate()
    {
        return dateformatter.format(signUpDate);
    }
}

Make sense?

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org