You might want to take a look at a project I created several years ago
that works pretty much like this.  I still find it occasionally
useful, although most of my frontends are GWT and javascript these
days:

http://tagonist.tigris.org/

It lets you use JSP files as controllers but keeps your Java code nice
and tidy.  Super-simple.

Jeff

On Fri, May 7, 2010 at 6:06 PM, Aaron Freeman <aaron.free...@layerz.com> wrote:
> Yes, that's exactly right.  In several instances we have many
> controllers that are written in JSP (pure JSTL code), that <c:import>
> our models (also in this case JSPs) and also <c:import> our views.
>
> Works great!
>
> The upside to it is: a) easier to code -- people with limited Java
> expertise can modify the controllers if they are not too complex (and
> rarely are), and b) you can change your controllers on the fly without
> having to restart Resin (primary reason we do this).
>
> Aaron
>
>
> On 5/7/2010 5:05 PM, Rachel McConnell wrote:
>> This comment isn't helpful I know but I am very curious about this.
>> The code you quoted is a tag library call using the EL.  How is that
>> not part of the UI?  Are you writing controllers in JSP somehow?
>>
>> Rachel
>>
>> On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman<aaron.free...@layerz.com>  
>> wrote:
>>
>>> This isn't in the UI layer.  This is in a controller.  At any rate there is
>>> a simple work around, but this sure doesn't seem like it should be
>>> generating an error.  If a property doesn't exist on an object it sure seems
>>> like the test for empty=true should work, and not throw a runtime error.
>>>
>>> At any rate there are easy workarounds in this case but workarounds make the
>>> code uglier.
>>>
>>> Aaron
>>>
>>>
>>> On 5/7/2010 3:57 PM, Jon Stevens wrote:
>>>
>>> I don't know if there is a way and it isn't something I'd depend on in the
>>> UI layer. Think of [class] like you'd think of an interface. You really
>>> should only put implementations of interfaces into the context. Otherwise,
>>> I'd consider putting a Map in there for the effect you want.
>>> jon
>>>
>>> On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman<aaron.free...@layerz.com>
>>> wrote:
>>>
>>>> Bummer, what's the proper way to test if a property exists then, since
>>>> ${!empty [class].[property]} isn't the correct way?
>>>>
>>>> Thanks,
>>>>
>>>> Aaron
>>>>
>>>>
>>>> On 5/7/2010 3:07 PM, Jon Stevens wrote:
>>>>
>>>> That is what JBoss does, so I'd say that Caucho fixed a bug.
>>>> jon
>>>>
>>>> On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman<aaron.free...@layerz.com>
>>>> wrote:
>>>>
>>>>> We are system testing Resin 4.0.6 with our old code base and found a
>>>>> curiosity.  The following code used to work, regardless of what "type"
>>>>> "receipt" is:
>>>>>
>>>>> <c:if test="${!empty receipt.details}">
>>>>>
>>>>> Under Resin 3.0.x if receipt was a HashMap and had a "details" property
>>>>> then it would return "true".  If it was a HashMap and did not have a
>>>>> details property, it would correctly return false.  And (most
>>>>> importantly), if receipt was _any_ other class, including built in java
>>>>> classes, it would just return false.  With Resin 4.0.6 it now throws an
>>>>> error:
>>>>>
>>>>> 'details' is an unknown bean property of 'java.math.BigDecimal'
>>>>>
>>>>> That's not the expected behavior is it?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>
>
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>


_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to