Re[2]: Pre Nested Extension Commit...
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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)?... 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
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...
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: mailto:[EMAIL PROTECTED] AB For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Best regards, Olegmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
