Re: Pre Nested Extension Commit...

[Arron Bates]

>
>
>I think the real proof of concept was when the nesting extension
>continued to work well after the multiapp changes. 
>
It was a non-event because you guys managed to separate the tags and 
such (let's call them "view" components), from everything else (the 
servlet etc. Lets for naming sake, call it... say... the "controller"). 
The beans I suppose we can call it the "model" or something... (VCM?)

;)

Arron.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pre Nested Extension Commit...

[Ted Husted]

Oleg V Alexeev wrote:
> Good. So, can you create mirror of existing tags with "nested" features
> with intention to merge "base" and "nested" tags together? If yes,
> then we don't need to support two different brunches of tags with
> similar code.

The existing tags are working quite well, and the nesting extension is
working quite well, so I would say we can maintain the status quo, and
just commit the extension as is. I'd continue to put off any serious
refactoring existing tags until more work is done about the Struts ->
JSTL migration. And Arron's already exist :)

I think the real proof of concept was when the nesting extension
continued to work well after the multiapp changes. 

Arron's site is here:

http://www.keyboardmonkey.com/struts/index.html


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pre Nested Extension Commit...

[Arron Bates]

Oleg V Alexeev wrote:

>AB> Making it one with the current library?...
>AB> It "can", but so can the html library. But for many reasons I go against 
>AB> it. One, the simple fact that they're all working off the same basic 
>AB> premise, the same relationships that the html tags work off of. So if 
>AB> it's done for one, it's done for all. If you do for all, it's another 
>AB> property which has to be added to each tag, and is entirely a lot more 
>AB> work with what I definitely feel is a less elegant solution in the end.
>
>AB> The clean and efficient markup needed for the nested tags is just... 
>AB> well... sexy!
>AB> :)
>
>Good. So, can you create mirror of existing tags with "nested" features
>with intention to merge "base" and "nested" tags together? If yes,
>then we don't need to support two different brunches of tags with
>similar code. 
>
They don't have similar code at all. The nested tags rely on the old 
tags to do exactly what they do best. They just link them together so 
that they have a parents and children etc. The difference between say, 
the code in the nested:equals tag is almost identical to that in the 
nested:text tag. It's just that they extend different classes to do what 
they do.

I'd recommend taking 10 minutes to take a look at the source for the 
nested tags to see just how separate they are.


Arron.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re[2]: Pre Nested Extension Commit...

[Oleg V Alexeev]

Hello Arron,

Thursday, January 17, 2002, 7:46:23 AM, you wrote:

AB>   Oleg V Alexeev wrote:

>>One point to make it one, because of all nested tags are extends tags
>>from different taglibs and use its own internal logic, common for all
>>nested tags. And another point is a little question about adding of
>>"nested logic" to the existing tags against of new taglib creation.
>>Can it be done?
>>
AB> Making it one with the current library?...
AB> It "can", but so can the html library. But for many reasons I go against 
AB> it. One, the simple fact that they're all working off the same basic 
AB> premise, the same relationships that the html tags work off of. So if 
AB> it's done for one, it's done for all. If you do for all, it's another 
AB> property which has to be added to each tag, and is entirely a lot more 
AB> work with what I definitely feel is a less elegant solution in the end.

AB> The clean and efficient markup needed for the nested tags is just... 
AB> well... sexy!
AB> :)

Good. So, can you create mirror of existing tags with "nested" features
with intention to merge "base" and "nested" tags together? If yes,
then we don't need to support two different brunches of tags with
similar code. 



-- 
Best regards,
 Olegmailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pre Nested Extension Commit...

[Arron Bates]

  Oleg V Alexeev wrote:

>One point to make it one, because of all nested tags are extends tags
>from different taglibs and use its own internal logic, common for all
>nested tags. And another point is a little question about adding of
>"nested logic" to the existing tags against of new taglib creation.
>Can it be done?
>
Making it one with the current library?...
It "can", but so can the html library. But for many reasons I go against 
it. One, the simple fact that they're all working off the same basic 
premise, the same relationships that the html tags work off of. So if 
it's done for one, it's done for all. If you do for all, it's another 
property which has to be added to each tag, and is entirely a lot more 
work with what I definitely feel is a less elegant solution in the end.

The clean and efficient markup needed for the nested tags is just... 
well... sexy!
:)


Arron.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pre Nested Extension Commit...

[Arron Bates]

>
>
>I'm not quite ready for that yet ... how about in contrib first?
>

No offense, but what's to be "ready" for?...
It's tested against your multi-app stuff. All works a treat, and being 
used by tons of happy campers.

Or I can just wait until you've played with it...


>Remember that all the struts-*.tld files are *generated* -- they are not
>maintained in source separately.  The same XML file that is the source of
>these is also used to produce the reference docco about the libraries.
>

Yup. Noticed that.


Arron.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pre Nested Extension Commit...

[Oleg V Alexeev]

Hello Arron,

Wednesday, January 16, 2002, 4:54:42 PM, you wrote:

AB> First of all, thanks for the votes peoples.

AB> Need to confirm something and ask opinions on another before I scuttle 
AB> the codebase...
AB> (need three +1's or 0's, or some -1's with explanations if you please) ...

AB> 1) The nested system is going into the main source tree (not contrib)?...

AB> 2) The TLD. The nested tags extend the other tags, so this basically 
AB> means a duplication of their library definition.
AB> To date I've just placed all the tags in the one TLD from the others. 
AB> Any overwhelming opinions to separate the descriptor into the separate 
AB> parts as the original library (means we would end up with "nest-html", 
AB> "nest-logic" or whatever).
AB> Keep it as one?...

One point to make it one, because of all nested tags are extends tags
from different taglibs and use its own internal logic, common for all
nested tags. And another point is a little question about adding of
"nested logic" to the existing tags against of new taglib creation.
Can it be done?

AB> 3) The new TLD's docco... To make sure that the new TLD is as current as
AB> it can be, I'll create it again rather than just use my current one. In 
AB> the other TLD's xml files there's a fair amount of docco. My intention 
AB> here is that any tag which is an extension of an original, I will remove 
AB> the docco with an exception of a line to say that "this is an extension 
AB> of [orig tag] tag of [orig tld].tld file". Those tags which are new for 
AB> the extension will have fresh docco. That way it'll keep the size of the 
AB> TLD down (if question two is +1), and save duplication of the docco and 
AB> it's maintenance.
AB> Refer docco for original tags?

I think that it is not good idea to copy/paste existing doc - make a
ref to the existing tag docs.

AB> I think that that's about what I need clarified before I commit this thing.

AB> Ta.
AB> (Ted: http://www.dictionary.com/cgi-bin/dict.pl?term=ta )

AB> Arron.





AB> --
AB> To unsubscribe, e-mail:   
AB> For additional commands, e-mail: 



-- 
Best regards,
 Olegmailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pre Nested Extension Commit...

[Craig R. McClanahan]

On Thu, 17 Jan 2002, Arron Bates wrote:

> Date: Thu, 17 Jan 2002 00:54:42 +1100
> From: Arron Bates <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Pre Nested Extension Commit...
>
> First of all, thanks for the votes peoples.
>
> Need to confirm something and ask opinions on another before I scuttle
> the codebase...
> (need three +1's or 0's, or some -1's with explanations if you please) ...
>
> 1) The nested system is going into the main source tree (not contrib)?...
>

I'm not quite ready for that yet ... how about in contrib first?

> 2) The TLD. The nested tags extend the other tags, so this basically
> means a duplication of their library definition.
> To date I've just placed all the tags in the one TLD from the others.
> Any overwhelming opinions to separate the descriptor into the separate
> parts as the original library (means we would end up with "nest-html",
> "nest-logic" or whatever).
> Keep it as one?...
>

If the new versions of the tags are exactly identical except for the name,
it might be feasible to tweak the XSLT stylesheet that creates TLDs and
make them both at once.  At a minimum, you might be able to use the same
input file with a different stylesheet.

> 3) The new TLD's docco... To make sure that the new TLD is as current as
> it can be, I'll create it again rather than just use my current one. In
> the other TLD's xml files there's a fair amount of docco. My intention
> here is that any tag which is an extension of an original, I will remove
> the docco with an exception of a line to say that "this is an extension
> of [orig tag] tag of [orig tld].tld file". Those tags which are new for
> the extension will have fresh docco. That way it'll keep the size of the
> TLD down (if question two is +1), and save duplication of the docco and
> it's maintenance.
> Refer docco for original tags?
>

Remember that all the struts-*.tld files are *generated* -- they are not
maintained in source separately.  The same XML file that is the source of
these is also used to produce the reference docco about the libraries.

> I think that that's about what I need clarified before I commit this thing.
>
> Ta.
> (Ted: http://www.dictionary.com/cgi-bin/dict.pl?term=ta )
>
> Arron.
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Pre Nested Extension Commit...

[Ted Husted]

Arron Bates wrote:
> 
> First of all, thanks for the votes peoples.
> 
> Need to confirm something and ask opinions on another before I scuttle
> the codebase...
> (need three +1's or 0's, or some -1's with explanations if you please) ...

Hey, you're a committer now, and entitled to exercise you're own best
judgment. We need an affirmative majority vote on a Release, but most
everything else is lazy consensus. If you believe someone might have a
contrary opinon, it's helpful to ask first and proactively resolve any
vetos. But, you don't need to fish for +1s -- just feel out the -1s
(just so you don't have undo things later). We like to err on the side
of people doing things :0)

But, to be sure, -1 on actually scuttling the codebase (ouch!), but +1
on proceeding to add the nesting extension to the main Struts
distribution.



> 1) The nested system is going into the main source tree (not contrib)?...

I'm thinking it belongs under taglibs with the rest of the gang. 


 
> 2) The TLD. The nested tags extend the other tags, so this basically
> means a duplication of their library definition.
> To date I've just placed all the tags in the one TLD from the others.
> Any overwhelming opinions to separate the descriptor into the separate
> parts as the original library (means we would end up with "nest-html",
> "nest-logic" or whatever).
> Keep it as one?...

A single nested.tld works for me.


> 3) The new TLD's docco... To make sure that the new TLD is as current as
> it can be, I'll create it again rather than just use my current one. In
> the other TLD's xml files there's a fair amount of docco. My intention
> here is that any tag which is an extension of an original, I will remove
> the docco with an exception of a line to say that "this is an extension
> of [orig tag] tag of [orig tld].tld file". Those tags which are new for
> the extension will have fresh docco. That way it'll keep the size of the
> TLD down (if question two is +1), and save duplication of the docco and
> it's maintenance.
> Refer docco for original tags?

I'd say so. Just document the extended features and other deviations,
and avoid the dual maintenance.


> I think that that's about what I need clarified before I commit this thing.
> 
> Ta.
> (Ted: http://www.dictionary.com/cgi-bin/dict.pl?term=ta )

Which pretty much sums up why you were nominated :)


> Arron.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Pre Nested Extension Commit...

[Arron Bates]

First of all, thanks for the votes peoples.

Need to confirm something and ask opinions on another before I scuttle 
the codebase...
(need three +1's or 0's, or some -1's with explanations if you please) ...

1) The nested system is going into the main source tree (not contrib)?...

2) The TLD. The nested tags extend the other tags, so this basically 
means a duplication of their library definition.
To date I've just placed all the tags in the one TLD from the others. 
Any overwhelming opinions to separate the descriptor into the separate 
parts as the original library (means we would end up with "nest-html", 
"nest-logic" or whatever).
Keep it as one?...

3) The new TLD's docco... To make sure that the new TLD is as current as 
it can be, I'll create it again rather than just use my current one. In 
the other TLD's xml files there's a fair amount of docco. My intention 
here is that any tag which is an extension of an original, I will remove 
the docco with an exception of a line to say that "this is an extension 
of [orig tag] tag of [orig tld].tld file". Those tags which are new for 
the extension will have fresh docco. That way it'll keep the size of the 
TLD down (if question two is +1), and save duplication of the docco and 
it's maintenance.
Refer docco for original tags?

I think that that's about what I need clarified before I commit this thing.

Ta.
(Ted: http://www.dictionary.com/cgi-bin/dict.pl?term=ta )

Arron.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: