struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shekhar Yadav <sya...@strongmail.com>
Subject Re: [proposal] Tag reorganization
Date Fri, 29 Dec 2006 23:17:32 GMT
I am sorry if I did not see previous notices.

These are typical tags that we are using:-

1.  <s:a href="${updateListStateURL}" theme="ajax" 
afterLoading="javascript: refreshWidgetContent('listDetails', 
'${listDetailsURL}'); ">
                            <s:property value="name"/>
                         </s:a>

2.  <!-- form submit -->
        <s:submit id="submit_next" cssClass="submit_next" 
cssStyle="display:none" name="submit_next" theme="ajax" 
resultDivId="pageContent"/>

3. And I am trying to still find stable use for <s:div ../> where it 
gets updated from onChange event of some other widget say select.
4. <s:select..> we want to use ajax but right now we are having issues 
with it messing our layout.. so until we fix that we are not using it.
5. We will need tabbedPanel but we have not got there yet, so I don't 
know of particular issues the changes might have for us.

So if you are saying that it is going to be simple replace of 
<s:select..> to <dojo:select..> and likewise for all other use cases I 
think we will be Ok.

- Shekhar

Musachy Barroso wrote:
> On top of that, the div, tabbedPanel, anchor and submit tags will have 
> almost no changes (except the redundant "beforeLoading" and 
> "afterLoading" which I think we are going to drop). Only the 
> DatePicker and TimePicker will be different.
>
> musachy
>
> Ian Roughley wrote:
>> If we go the <dojo:select ... /> from <s:select theme="ajax" ... /> 
>> route, then it should be a simple global find and replace.
>>
>> I am surprised at such a large use of the tags though.  I've asked 
>> more than a couple of times if anyone was using them, and there was 
>> never a response.
>>
>> /Ian
>>
>>
>>
>> Shekhar Yadav wrote:
>>> We are using 2.0.1 and we are using form/div with ajax based theme. Is
>>> it going to be major problem for us to migrate to new tags. If so what
>>> are you recommendations, we are in process of building and only half 
>>> way
>>> through. I don't want to create 250 screens with tags that are going to
>>> be outdated by the time we release the app.
>>>
>>> - Shekhar
>>>
>>> -----Original Message-----
>>> From: Ian Roughley [mailto:ian@fdar.com] Sent: Thursday, December 
>>> 28, 2006 7:36 AM
>>> To: Struts Developers List
>>> Subject: Re: [proposal] Tag reorganization
>>>
>>> I'm torn - I like the fact that we are getting the ajax code out of 
>>> the base, but especially for webwork->s2 upgrades there is going to 
>>> be more work.  The other thing is that 2.0.2 is still beta, and 
>>> frankly I don't think there is that many people using the tags at 
>>> the moment, so this would be a good time to make the change.
>>>
>>> /Ian
>>>
>>>
>>> David H. DeWolf wrote:
>>>  
>>>> That's what I'm imagining too. . .and we're agreeing that this 
>>>> incompatibility is a pill we have to swallow.
>>>>
>>>> Ian Roughley wrote:
>>>>   
>>>>> I think I am missing something here - how will the tags be 
>>>>> invoked?  It will need to be a new tld with a new name space, 
>>>>> right?  Something
>>>>>       
>>>
>>>  
>>>>> like <dojo:select ... /> rather than <s:select theme="ajax"
... /> 
>>>>> - so there will be a compatibility issue, but all the 
>>>>> functionality will be moved forward.
>>>>>
>>>>> /Ian
>>>>>
>>>>>
>>>>> David H. DeWolf wrote:
>>>>>     
>>>>>> Ted Husted wrote:
>>>>>>       
>>>>>>> Don mentioned a separate tag library, so that would indicate
>>>>>>>           
>>> another
>>>  
>>>>>>> prefix, but there'd be no reason why the internal tag syntax
would
>>>>>>> change.
>>>>>>>
>>>>>>> To keep the codebase manageable, I believe we do need to make
this
>>>>>>> change, and I'd rather make it now while we are in our first
beta
>>>>>>> series than after the first Struts 2 GA. The plugin model might
>>>>>>>           
>>> also
>>>  
>>>>>>> open the door to other AJAX implementations of the same tags.
>>>>>>>           
>>>>>> I agree.  I like it, but just wanted to make sure we think 
>>>>>> through the compatibility changes before we make a decision.
>>>>>>
>>>>>> In essence we're saying that this change is more important than 
>>>>>> backwards compat of this one tag and we're willing to live with 
>>>>>> those repercussions.   I'm on board with that.
>>>>>>
>>>>>>
>>>>>>       
>>>>>>> -T.
>>>>>>>
>>>>>>> On 12/27/06, David H. DeWolf <ddewolf@apache.org> wrote:
>>>>>>>         
>>>>>>>> Ok, as long as we keep the tag prefixes and tag names once
they
>>>>>>>>             
>>> are
>>>  
>>>>>>>> abstracted from the plugin.
>>>>>>>>
>>>>>>>> At one point we talked about having a simple version which
is 
>>>>>>>> extended
>>>>>>>> by the dojo version and added additional (dojo-specific)

>>>>>>>> featuers.  It
>>>>>>>> seems like the current names would be more likely be used
for 
>>>>>>>> the core
>>>>>>>> tags - not the dojo-enhanced ones.
>>>>>>>>
>>>>>>>> Ted Husted wrote:
>>>>>>>>           
>>>>>>>>> A struts-dojo plugin shouldn't change the tag syntax.
It 
>>>>>>>>> should               
>>>>>>>> just
>>>>>>>>           
>>>>>>>>> be a matter of adding the JAR, as we do for Spring, and

>>>>>>>>>               
>>>>>>>> JasperReports,
>>>>>>>>           
>>>>>>>>> and Tiles, so forth.
>>>>>>>>>
>>>>>>>>> On 12/27/06, David H. DeWolf <ddewolf@apache.org>
wrote:
>>>>>>>>>             
>>>>>>>>>> Nope, that's the one I'm talking about.  I got the
impression 
>>>>>>>>>>                 
>>>>>>>> we were
>>>>>>>>           
>>>>>>>>>> going to keep it as is and thus break backwards compatibility

>>>>>>>>>>                 
>>>>>>>> in 2.0.2
>>>>>>>>           
>>>>>>>>>> -- and then mess with it again it when we create
the plugin. .
>>>>>>>>>>                 
>>> .
>>>  
>>>>>>>>>> David
>>>>>>>>>>                 
>>>>>>>           
>>> ---------------------------------------------------------------------
>>>  
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>         
>>> ---------------------------------------------------------------------
>>>  
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>         
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>       
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>     
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>   
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


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


Mime
View raw message