jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vit Timchishin" <t...@gtech-ua.com>
Subject Re: Using Image Taglib when J2EE application is inside (an unpacked) war file.
Date Mon, 07 Jun 2004 11:06:25 GMT
On Mon,  7 Jun 2004 09:30:08 +0300, HДrЖ wrote:

>The idea of applying MVC model into this problem is good as an ideal solution.
>In our case, this approach is not possible due to practical reasons. Some of our
>services are bought from other vendors/system suppliers, and we don't have much
>control over the way they work. We only have control on the view layer. And,
>from our point of view, this problem mostly has to do with the view layer: How
>to show the large image files on a web page (located behind an URI) as smaller
>representations, so that our clients may retrieve the images with an acceptable
>delay, and so that the images are correctly positioned in the UI.
>Our UI designer is not interested in where the converted files are located,
>in fact I agree that it would be better if he even didn't have a change of
>(miss)configuring the image directory, nor the URI for accessing it. The
>original URI mentioned as img:src attribute should be enough for the page designer.
>The tag, on the other hand, needs to know where to put the converted files (if
>not using default dir). This is where we have a dilemma. Tag implementation
>needs some information that we don't want to specify on a web page. We don't
>want to mix this data with the view layer of our application, since it is data
>about the internal implementation of the tag. What about if we had a possibility
>of giving this information to the tag, but not as an argument. There are other
>ways of providing configuration information for Java classes. Any comments?

I'd recomment you to create you own tag using tag files that simply calls image tag providing
attributes. This would not add complexity to image taglib and won't make your designer add
Another options would be for image taglib to take this information by default from the web-app

>Matti HДrЖ
>Lainaus Michael McGrady <michael@michaelmcgrady.com>:
>> There is a sense in which the location of the image file is independent of 
>> the Image taglib.  For example, I do the following:
>> <img:image
>>    src='resource.CRACKWILLOW?file_type=gif&file_name=new.gif'
>>    name='i18n3.gif' >
>>    <img:transparency
>>      level='255'/>
>>    <img:resize
>>      width='200'
>>      height='50'/>
>>    <img:text
>>      text='<%= original %>'
>>      font='Arial Unicode MS'
>>      size='40'
>>      bold='true'
>>      x='10%'
>>      y='80%'
>>      color='0x000000'/>
>> </img:image>
>> As you can see, I do not use a URL.  I try to avoid URLs at all when 
>> accessing resources for a web browser, because they are so dumb.  Rather, I
>> use a "protocol" that calls the controller of the MVC and the controller 
>> knows what to do with the request independent of any knowledge of the 
>> browser.  I suspect that you may need to do this with your problem, and 
>> that your problem is not one that the Image taglib should be solving.
>> Michael
>> At 02:44 AM 6/4/2004, Matti HДrЖ wrote:
>> >Hi,
>> >
>> >In some of our services, we have JBoss/Jetty as application server. Jetty
>> does
>> >not unpack the war file of our application while in startup, like Tomcat
>> does.
>> >This results in Image Taglib being unable to create a directory 
>> >"gen-images" for
>> >caching the created, resized image. There is a "dir" attribute for the 
>> >tag, but
>> >this attribute is handled as relative to the context path, which points, 
>> >again,
>> >inside the war file. So, using the "dir" attribute does not help with the
>> >problem. Is there a way to specify absolute directory for image caching, or
>> is
>> >there another way of being able to use the Image Tag library with
>> environments
>> >where the war files are never unpacked for execution?
>> >
>> >With best regards,
>> >Matti HДrЖ
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>> This electronic mail  transmission and any accompanying documents contain 
>> information belonging to the sender which may be confidential and legally 
>> privileged.  This information is intended only for the use of the 
>> individual or entity to whom this electronic mail transmission was sent as 
>> indicated above. If you are not the intended recipient, any disclosure, 
>> copying, distribution, or action taken in reliance on the contents of the 
>> information contained in this transmission is strictly prohibited.  If you 
>> have received this transmission in error, please delete the message.  Thank
>> you  
>To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

С уважением,
Виталий Валериевич Тимчишин,
руководитель отдела ASL
ООО "Голден Технолоджис"

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

View raw message