You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Greg Reddin <gr...@apache.org> on 2006/03/21 19:23:42 UTC
Standalone Tiles: Status and Call for Help
I've just checked in the last taglib refactoring work that I can
think of. That turned out to be a much smaller chunk of work than I
had thought. If you're following the wiki page[1] that means
Milestone 2 in the 4-step process to release is largely complete.
There's one remaining gaping hole that worries me. In all the
refactoring I've done almost all the use cases in my applications
have worked without issue. But I suspect I'm only scratching the
surface of what you can do with Tiles and I don't have much
confidence that the other stuff will work yet.
So, if there are people willing to help, I think we can take the
development in 2 simultaneous directions: 1) building test suites
and 2) moving on to Milestone 3: Remove Servlet API dependencies.
Ideally, I'd like to see test cases passing before we move on the
Milestone 3, but in the interest of getting things done, I see no
reason we can't start accepting patches for it.
As for the test cases, I'm not very familiar with Cactus or some
other web app testing packages. So to save time, I've been testing
using a simple web application and clicking through. I will
eventually move these tests to a better testing platform, but the
current method is working for now. You can see a very limited list
of things I'm currently testing for on the wiki page. I'll try to
add the rest. I can also check my test app into the sandbox if it
will help. Maybe someone can go ahead and start the process of
converting them to Cactus or whatever they need to be. In the
meantime, I'd love to hear use cases that are not yet documented so I
can test for them. Please send me your use cases. I'll accept them
offlist either described in an email or with sample JSPs, or post
them to the list, or add them to the wiki page. I'll feel a lot
better about things if I have a more comprehensive set of tests.
In addition I'm sure there are things that have been raised that I
haven't addressed. especially from Antonio Petrelli. Please let me
know of those.
Thanks,
Greg
[1] http://wiki.apache.org/struts/StandaloneTiles#preview
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Greg Reddin <gr...@apache.org>.
On May 1, 2006, at 2:27 PM, Wendy Smoak wrote:
> Thanks. Which build are you using? I'd like to arrange Standalone
> Tiles into modules for Maven 2 so that the example app can live beside
> tiles-core, rather than in a separate sandbox project.
Yes, that would be awesome! I am now using the Maven 2 build. The
SAX issues I was having were resolved by updating my Surefire plugin.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Wendy Smoak <ws...@gmail.com>.
On 5/1/06, Greg Reddin <gr...@apache.org> wrote:
> Done. It's not much to speak of, but it's a start. I checked it
> into sandbox/tiles-test. The lib directory is empty. It will need
> the following jars to run:
Thanks. Which build are you using? I'd like to arrange Standalone
Tiles into modules for Maven 2 so that the example app can live beside
tiles-core, rather than in a separate sandbox project.
I don't want to disrupt your work, though.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Greg Reddin <gr...@apache.org>.
On Apr 28, 2006, at 3:06 PM, Wendy Smoak wrote:
> Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
> that each Action 1 example app will at least deploy and display its
> default page. If you'll check in the app you mentioned,
Done. It's not much to speak of, but it's a start. I checked it
into sandbox/tiles-test. The lib directory is empty. It will need
the following jars to run:
commons-beanutils-1.7.0.jar
commons-chain-1.0.jar
commons-codec.jar
commons-collections.jar
commons-digester-1.6.jar
commons-el.jar
commons-fileupload-1.0.jar
commons-logging-1.0.4.jar
commons-validator-1.2.0.jar
tiles-core-0.2-SNAPSHOT.jar
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action1] Improving our tests -- long [was Re: Standalone Tiles:
Status and Call for Help]
Posted by Don Brown <mr...@twdata.org>.
If infrastructure would approve my request to run Jive on an ASF server, we wouldn't be having this discussion :)
In the meantime, you can "watch" the WebWork developer forum, which contains the chat transcripts posted each night:
http://forums.opensymphony.com/watches!add.jspa?forumID=32
Don
Martin Cooper wrote:
> On 4/28/06, James Mitchell <jm...@apache.org> wrote:
>>
>> So, after a long winded discussion on the WW Chat line....(no need to
>> rehash, it's in your inbox -- or will be)...
>
>
> I've seen people make this type of comment before, but I have yet to see
> any
> of these chat transcripts show up in my mailbox. I'd appreciate it if
> someone could fix that, because right now, there are development
> discussions
> going on that are not visible to everyone on this list, which is not good.
>
> --
> Martin Cooper
>
>
> several ideas were
>> mentioned, and so I thought I'd throw it out there for comment.
>>
>> Patrick has graciously offered to provide the Struts community with
>> free beer and back rubs!!!! woo hooo!!! <- ok, just kidding about
>> the beer. Patrick has offered us free resources for automated testing.
>>
>> I'll let Patrick explain in greater detail as I'm not that familiar
>> with what he has to offer and I don't want to misquote.
>>
>> The discussion (as you've read from the chat) originally started just
>> as chatter about the below plugin (TestGen4Web) and what we could do
>> with it to help with automated testing.
>>
>> There is plenty of documentation out there for TestGen4Web, but let
>> me explain how this thing works and where I think we can leverage it
>> for our own needs. TestGen4Web is a FireFox plugin that let's you
>> record a session (as mentioned below). Once you push record,
>> everything you do is remembered and you can save the file locally
>> right from the toolbar. You can even load an existing script and
>> play it.
>>
>> If you have downloaded the translator, you can generate an HttpUnit
>> java source from the saved .xml file that implements everything you
>> did with the mouse and keyboard that is a ready to run HttpUnit test
>> class.
>>
>> For example, this is what is generated when I recorded a session for
>> the struts-blank application:
>>
>>
>> <?xml version='1.0' encoding='UTF-8'?>
>> <tg4w version="0.38.1">
>> <actions>
>> <action type="goto" refresh="true" step="0">
>> <xpath><![CDATA[window.location.href]]></xpath>
>> <value><![CDATA[http://localhost:8080/struts-blank/]]></
>> value>
>> </action>
>> <action type="verify-title" refresh="true" step="1">
>> <xpath><![CDATA[*]]></xpath>
>> <value><![CDATA[Struts Blank Application]]></value>
>> </action>
>> <action type="assert-text-exists" step="2">
>> <xpath><![CDATA[*]]></xpath>
>> <value><![CDATA[Welcome!]]></value>
>> </action>
>> </actions>
>> </tg4w>
>>
>>
>> You can see in step 0 I hit the url for the struts-blank app. Then
>> in step 1 the title is verified and step 2 verifies that the text
>> "Welcome!" is in the page. I did step 2 ("assert-text-exists") by
>> highlighting the Welcome! text and right click -> Assert -> Verify Text.
>>
>> The same .xml file can also be used to generate a Selenium
>> configuration xml file that does the same test.
>>
>> Currently there isn't a Maven 2 plugin for the process of translating
>> from xml to java and that's where I come in. What comes with
>> TestGen4Web is an ant build that does the job. I'm currently working
>> on a new Maven 2 plugin that handles this and it should be finished
>> by the time you read this. Configuring the test to run as part of
>> the build will be the tricky (Wendy? help?!?!) part. With this
>> plugin, you won't have to download the translator.
>>
>> Like most things in Maven, you aren't forced into a directory
>> structure, but for this purpose I propose we do this:
>>
>> struts
>> + action
>> + apps
>> + blank
>> + cookbook
>> + ...
>> + ...
>> + TestGen4Web
>> + src
>> + main
>> + scripts <- new (.xml) scripts go here
>> + target
>> + gensrc <- scripts get gen'd to here (.java)
>> + classes <- the plugin would compile the test to here
>>
>> (Just to be clear, the only thing we should be keeping in svn is the
>> xml scripts)
>>
>> This plugin will generate both HttpUnit (.java) and Selenium (.xml)
>> sources, and this would is where Patrick's process could pick up the
>> Selenium config.
>>
>> And so, going forward with this plugin, all we would need to do is
>> create a new script (e.g. blank-validate-welcome.xml) and put it
>> under TestGen4Web/src/main/scripts and you are done. Obviously we
>> would want to be consistent with script naming, personally I would
>> prefer that they be verbose and in the event that a new script is
>> needed to verify a specific bug, the bug number might also be in the
>> name. One other option we might consider is keeping a README.txt in
>> that directory if any further details are needed.
>>
>> These scripts would greatly speed up the release process since it
>> would basically do the equivalent of about 2 or more hours of what
>> used to be done manually.
>>
>>
>> However, the fun doesn't stop here. I'm not sure how clear I was in
>> the chat log about my idea for a linear set of pages to test the
>> taglibs, but what I had in mind would be to extend the cookbook and
>> provide many more examples that demonstrate the various ways some
>> tags can be used.
>>
>> I'm not sure if we want to go the same route as the taglib tests by
>> providing a test for every possible combination of attributes for
>> every tag and some with multiple scenarios for tags that supported
>> different ways to provide values for a given attribute. Whatever the
>> case, I'm excited about being able to add new tests that are also
>> directly adding to the demo apps / tutorials.
>>
>> When all is said and done, when you do a full build, the tests will
>> be executed and a report will be generated as part of the site
>> documentation. But the report part hasn't been written yet.
>>
>> What do you think?
>>
>>
>> --
>> James Mitchell
>>
>>
>>
>>
>> On Apr 28, 2006, at 6:13 PM, James Mitchell wrote:
>>
>> Speaking of testing.....I recently came across a really cool plugin
>> for FireFox. It's called TestGen4Web and it let's you record and
>> save a browser session.
>>
>> <feedback type="anticipated">
>> What the heck is a browser session?
>> </feedback>
>>
>> Oh, I'm glad you asked. It is the set of step that you (as a user)
>> do within a browser window. You can then have the saved session
>> (which is in xml by the way) converted to an HttpUnit test.
>>
>> https://addons.mozilla.org/firefox/1385/
>>
>>
>>
>> --
>> James Mitchell
>>
>>
>>
>>
>> On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote:
>>
>> On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
>>
>> As for the test cases, I'm not very familiar with Cactus or some
>> other web app testing packages. So to save time, I've been testing
>> using a simple web application and clicking through.
>> ...
>> I can also check my test app into the sandbox if it
>> will help. Maybe someone can go ahead and start the process of
>> converting them to Cactus or whatever they need to be.
>>
>> Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
>> that each Action 1 example app will at least deploy and display its
>> default page. If you'll check in the app you mentioned, I'll add a
>> simple test and you can try it out. Warning: it might require a
>> little rearranging for Maven 2. :)
>>
>> Cactus tests are beyond me at this point, I still haven't figured out
>> why the ones for Struts Taglib don't work.
>>
>> Thanks,
>> --
>> Wendy
>>
>> ---------------------------------------------------------------------
>> 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
Re: [action1] Improving our tests -- long [was Re: Standalone Tiles: Status and Call for Help]
Posted by Martin Cooper <ma...@apache.org>.
On 4/28/06, James Mitchell <jm...@apache.org> wrote:
>
> So, after a long winded discussion on the WW Chat line....(no need to
> rehash, it's in your inbox -- or will be)...
I've seen people make this type of comment before, but I have yet to see any
of these chat transcripts show up in my mailbox. I'd appreciate it if
someone could fix that, because right now, there are development discussions
going on that are not visible to everyone on this list, which is not good.
--
Martin Cooper
several ideas were
> mentioned, and so I thought I'd throw it out there for comment.
>
> Patrick has graciously offered to provide the Struts community with
> free beer and back rubs!!!! woo hooo!!! <- ok, just kidding about
> the beer. Patrick has offered us free resources for automated testing.
>
> I'll let Patrick explain in greater detail as I'm not that familiar
> with what he has to offer and I don't want to misquote.
>
> The discussion (as you've read from the chat) originally started just
> as chatter about the below plugin (TestGen4Web) and what we could do
> with it to help with automated testing.
>
> There is plenty of documentation out there for TestGen4Web, but let
> me explain how this thing works and where I think we can leverage it
> for our own needs. TestGen4Web is a FireFox plugin that let's you
> record a session (as mentioned below). Once you push record,
> everything you do is remembered and you can save the file locally
> right from the toolbar. You can even load an existing script and
> play it.
>
> If you have downloaded the translator, you can generate an HttpUnit
> java source from the saved .xml file that implements everything you
> did with the mouse and keyboard that is a ready to run HttpUnit test
> class.
>
> For example, this is what is generated when I recorded a session for
> the struts-blank application:
>
>
> <?xml version='1.0' encoding='UTF-8'?>
> <tg4w version="0.38.1">
> <actions>
> <action type="goto" refresh="true" step="0">
> <xpath><![CDATA[window.location.href]]></xpath>
> <value><![CDATA[http://localhost:8080/struts-blank/]]></
> value>
> </action>
> <action type="verify-title" refresh="true" step="1">
> <xpath><![CDATA[*]]></xpath>
> <value><![CDATA[Struts Blank Application]]></value>
> </action>
> <action type="assert-text-exists" step="2">
> <xpath><![CDATA[*]]></xpath>
> <value><![CDATA[Welcome!]]></value>
> </action>
> </actions>
> </tg4w>
>
>
> You can see in step 0 I hit the url for the struts-blank app. Then
> in step 1 the title is verified and step 2 verifies that the text
> "Welcome!" is in the page. I did step 2 ("assert-text-exists") by
> highlighting the Welcome! text and right click -> Assert -> Verify Text.
>
> The same .xml file can also be used to generate a Selenium
> configuration xml file that does the same test.
>
> Currently there isn't a Maven 2 plugin for the process of translating
> from xml to java and that's where I come in. What comes with
> TestGen4Web is an ant build that does the job. I'm currently working
> on a new Maven 2 plugin that handles this and it should be finished
> by the time you read this. Configuring the test to run as part of
> the build will be the tricky (Wendy? help?!?!) part. With this
> plugin, you won't have to download the translator.
>
> Like most things in Maven, you aren't forced into a directory
> structure, but for this purpose I propose we do this:
>
> struts
> + action
> + apps
> + blank
> + cookbook
> + ...
> + ...
> + TestGen4Web
> + src
> + main
> + scripts <- new (.xml) scripts go here
> + target
> + gensrc <- scripts get gen'd to here (.java)
> + classes <- the plugin would compile the test to here
>
> (Just to be clear, the only thing we should be keeping in svn is the
> xml scripts)
>
> This plugin will generate both HttpUnit (.java) and Selenium (.xml)
> sources, and this would is where Patrick's process could pick up the
> Selenium config.
>
> And so, going forward with this plugin, all we would need to do is
> create a new script (e.g. blank-validate-welcome.xml) and put it
> under TestGen4Web/src/main/scripts and you are done. Obviously we
> would want to be consistent with script naming, personally I would
> prefer that they be verbose and in the event that a new script is
> needed to verify a specific bug, the bug number might also be in the
> name. One other option we might consider is keeping a README.txt in
> that directory if any further details are needed.
>
> These scripts would greatly speed up the release process since it
> would basically do the equivalent of about 2 or more hours of what
> used to be done manually.
>
>
> However, the fun doesn't stop here. I'm not sure how clear I was in
> the chat log about my idea for a linear set of pages to test the
> taglibs, but what I had in mind would be to extend the cookbook and
> provide many more examples that demonstrate the various ways some
> tags can be used.
>
> I'm not sure if we want to go the same route as the taglib tests by
> providing a test for every possible combination of attributes for
> every tag and some with multiple scenarios for tags that supported
> different ways to provide values for a given attribute. Whatever the
> case, I'm excited about being able to add new tests that are also
> directly adding to the demo apps / tutorials.
>
> When all is said and done, when you do a full build, the tests will
> be executed and a report will be generated as part of the site
> documentation. But the report part hasn't been written yet.
>
> What do you think?
>
>
> --
> James Mitchell
>
>
>
>
> On Apr 28, 2006, at 6:13 PM, James Mitchell wrote:
>
> Speaking of testing.....I recently came across a really cool plugin
> for FireFox. It's called TestGen4Web and it let's you record and
> save a browser session.
>
> <feedback type="anticipated">
> What the heck is a browser session?
> </feedback>
>
> Oh, I'm glad you asked. It is the set of step that you (as a user)
> do within a browser window. You can then have the saved session
> (which is in xml by the way) converted to an HttpUnit test.
>
> https://addons.mozilla.org/firefox/1385/
>
>
>
> --
> James Mitchell
>
>
>
>
> On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote:
>
> On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
>
> As for the test cases, I'm not very familiar with Cactus or some
> other web app testing packages. So to save time, I've been testing
> using a simple web application and clicking through.
> ...
> I can also check my test app into the sandbox if it
> will help. Maybe someone can go ahead and start the process of
> converting them to Cactus or whatever they need to be.
>
> Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
> that each Action 1 example app will at least deploy and display its
> default page. If you'll check in the app you mentioned, I'll add a
> simple test and you can try it out. Warning: it might require a
> little rearranging for Maven 2. :)
>
> Cactus tests are beyond me at this point, I still haven't figured out
> why the ones for Struts Taglib don't work.
>
> Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
>
>
Re: [action1] Improving our tests -- long [was Re: Standalone Tiles: Status and Call for Help]
Posted by James Mitchell <jm...@apache.org>.
One thing that I might have blurred the lines on is that there are
basically 2 things being proposed here with respect to TestGen4Web.
#1 - The ability to easily create test scripts for cases that
can only be proven and solved via a deployed app (and
without cactus)
#2 - A set of scripts (that happen to be executed just like #1,
yet serve a little different purpose) that recursively
run through the cookbook links and assert success on the
page after every click.
While the existing cookbook pages usually offer some kind of
interactivity (enter some data and see it work differently for
different values), the new pages that demonstrate the taglibs (or
test them, depending on your purpose) would be required to show some
kind of success message that can be asserted. That value should not
appear if the test fails. The success message will need to be
consistent if the tests are to be recursive. Meaning that adding new
tests (recipes) to an existing page (chapter) would only require that
a new description and link be added and when clicked on will end up
showing a page where the text could be asserted. Again, that applies
to the pages that test (and demonstrate) taglibs.
So, to mentally reorg the cookbook. Instead of this:
--------------
Simple Form using ActionForm Execute <- link that gets
clicked and tested
Simple Form using DynaActionForm Execute <- same
Select and Options tags Execute <- same
...
(and on down the page)
...
--------------
We might have a Table of contents as an index that links to pages
like the one above.
If no one objects, I'll proceed on it.
--
James Mitchell
On Apr 28, 2006, at 11:36 PM, James Mitchell wrote:
> So, after a long winded discussion on the WW Chat line....(no need
> to rehash, it's in your inbox -- or will be)... several ideas were
> mentioned, and so I thought I'd throw it out there for comment.
>
> Patrick has graciously offered to provide the Struts community with
> free beer and back rubs!!!! woo hooo!!! <- ok, just kidding about
> the beer. Patrick has offered us free resources for automated
> testing.
>
> I'll let Patrick explain in greater detail as I'm not that familiar
> with what he has to offer and I don't want to misquote.
>
> The discussion (as you've read from the chat) originally started
> just as chatter about the below plugin (TestGen4Web) and what we
> could do with it to help with automated testing.
>
> There is plenty of documentation out there for TestGen4Web, but let
> me explain how this thing works and where I think we can leverage
> it for our own needs. TestGen4Web is a FireFox plugin that let's
> you record a session (as mentioned below). Once you push record,
> everything you do is remembered and you can save the file locally
> right from the toolbar. You can even load an existing script and
> play it.
>
> If you have downloaded the translator, you can generate an HttpUnit
> java source from the saved .xml file that implements everything you
> did with the mouse and keyboard that is a ready to run HttpUnit
> test class.
>
> For example, this is what is generated when I recorded a session
> for the struts-blank application:
>
>
> <?xml version='1.0' encoding='UTF-8'?>
> <tg4w version="0.38.1">
> <actions>
> <action type="goto" refresh="true" step="0">
> <xpath><![CDATA[window.location.href]]></xpath>
> <value><![CDATA[http://localhost:8080/struts-blank/]]></
> value>
> </action>
> <action type="verify-title" refresh="true" step="1">
> <xpath><![CDATA[*]]></xpath>
> <value><![CDATA[Struts Blank Application]]></value>
> </action>
> <action type="assert-text-exists" step="2">
> <xpath><![CDATA[*]]></xpath>
> <value><![CDATA[Welcome!]]></value>
> </action>
> </actions>
> </tg4w>
>
>
> You can see in step 0 I hit the url for the struts-blank app. Then
> in step 1 the title is verified and step 2 verifies that the text
> "Welcome!" is in the page. I did step 2 ("assert-text-exists") by
> highlighting the Welcome! text and right click -> Assert -> Verify
> Text.
>
> The same .xml file can also be used to generate a Selenium
> configuration xml file that does the same test.
>
> Currently there isn't a Maven 2 plugin for the process of
> translating from xml to java and that's where I come in. What
> comes with TestGen4Web is an ant build that does the job. I'm
> currently working on a new Maven 2 plugin that handles this and it
> should be finished by the time you read this. Configuring the test
> to run as part of the build will be the tricky (Wendy? help?!?!)
> part. With this plugin, you won't have to download the translator.
>
> Like most things in Maven, you aren't forced into a directory
> structure, but for this purpose I propose we do this:
>
> struts
> + action
> + apps
> + blank
> + cookbook
> + ...
> + ...
> + TestGen4Web
> + src
> + main
> + scripts <- new (.xml) scripts go here
> + target
> + gensrc <- scripts get gen'd to here (.java)
> + classes <- the plugin would compile the test to here
>
> (Just to be clear, the only thing we should be keeping in svn is
> the xml scripts)
>
> This plugin will generate both HttpUnit (.java) and Selenium (.xml)
> sources, and this would is where Patrick's process could pick up
> the Selenium config.
>
> And so, going forward with this plugin, all we would need to do is
> create a new script (e.g. blank-validate-welcome.xml) and put it
> under TestGen4Web/src/main/scripts and you are done. Obviously we
> would want to be consistent with script naming, personally I would
> prefer that they be verbose and in the event that a new script is
> needed to verify a specific bug, the bug number might also be in
> the name. One other option we might consider is keeping a
> README.txt in that directory if any further details are needed.
>
> These scripts would greatly speed up the release process since it
> would basically do the equivalent of about 2 or more hours of what
> used to be done manually.
>
>
> However, the fun doesn't stop here. I'm not sure how clear I was
> in the chat log about my idea for a linear set of pages to test the
> taglibs, but what I had in mind would be to extend the cookbook and
> provide many more examples that demonstrate the various ways some
> tags can be used.
>
> I'm not sure if we want to go the same route as the taglib tests by
> providing a test for every possible combination of attributes for
> every tag and some with multiple scenarios for tags that supported
> different ways to provide values for a given attribute. Whatever
> the case, I'm excited about being able to add new tests that are
> also directly adding to the demo apps / tutorials.
>
> When all is said and done, when you do a full build, the tests will
> be executed and a report will be generated as part of the site
> documentation. But the report part hasn't been written yet.
>
> What do you think?
>
>
> --
> James Mitchell
>
>
>
>
> On Apr 28, 2006, at 6:13 PM, James Mitchell wrote:
>
> Speaking of testing.....I recently came across a really cool plugin
> for FireFox. It's called TestGen4Web and it let's you record and
> save a browser session.
>
> <feedback type="anticipated">
> What the heck is a browser session?
> </feedback>
>
> Oh, I'm glad you asked. It is the set of step that you (as a user)
> do within a browser window. You can then have the saved session
> (which is in xml by the way) converted to an HttpUnit test.
>
> https://addons.mozilla.org/firefox/1385/
>
>
>
> --
> James Mitchell
>
>
>
>
> On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote:
>
> On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
>
> As for the test cases, I'm not very familiar with Cactus or some
> other web app testing packages. So to save time, I've been testing
> using a simple web application and clicking through.
> ...
> I can also check my test app into the sandbox if it
> will help. Maybe someone can go ahead and start the process of
> converting them to Cactus or whatever they need to be.
>
> Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
> that each Action 1 example app will at least deploy and display its
> default page. If you'll check in the app you mentioned, I'll add a
> simple test and you can try it out. Warning: it might require a
> little rearranging for Maven 2. :)
>
> Cactus tests are beyond me at this point, I still haven't figured out
> why the ones for Struts Taglib don't work.
>
> Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
[action1] Improving our tests -- long [was Re: Standalone Tiles: Status and Call for Help]
Posted by James Mitchell <jm...@apache.org>.
So, after a long winded discussion on the WW Chat line....(no need to
rehash, it's in your inbox -- or will be)... several ideas were
mentioned, and so I thought I'd throw it out there for comment.
Patrick has graciously offered to provide the Struts community with
free beer and back rubs!!!! woo hooo!!! <- ok, just kidding about
the beer. Patrick has offered us free resources for automated testing.
I'll let Patrick explain in greater detail as I'm not that familiar
with what he has to offer and I don't want to misquote.
The discussion (as you've read from the chat) originally started just
as chatter about the below plugin (TestGen4Web) and what we could do
with it to help with automated testing.
There is plenty of documentation out there for TestGen4Web, but let
me explain how this thing works and where I think we can leverage it
for our own needs. TestGen4Web is a FireFox plugin that let's you
record a session (as mentioned below). Once you push record,
everything you do is remembered and you can save the file locally
right from the toolbar. You can even load an existing script and
play it.
If you have downloaded the translator, you can generate an HttpUnit
java source from the saved .xml file that implements everything you
did with the mouse and keyboard that is a ready to run HttpUnit test
class.
For example, this is what is generated when I recorded a session for
the struts-blank application:
<?xml version='1.0' encoding='UTF-8'?>
<tg4w version="0.38.1">
<actions>
<action type="goto" refresh="true" step="0">
<xpath><![CDATA[window.location.href]]></xpath>
<value><![CDATA[http://localhost:8080/struts-blank/]]></
value>
</action>
<action type="verify-title" refresh="true" step="1">
<xpath><![CDATA[*]]></xpath>
<value><![CDATA[Struts Blank Application]]></value>
</action>
<action type="assert-text-exists" step="2">
<xpath><![CDATA[*]]></xpath>
<value><![CDATA[Welcome!]]></value>
</action>
</actions>
</tg4w>
You can see in step 0 I hit the url for the struts-blank app. Then
in step 1 the title is verified and step 2 verifies that the text
"Welcome!" is in the page. I did step 2 ("assert-text-exists") by
highlighting the Welcome! text and right click -> Assert -> Verify Text.
The same .xml file can also be used to generate a Selenium
configuration xml file that does the same test.
Currently there isn't a Maven 2 plugin for the process of translating
from xml to java and that's where I come in. What comes with
TestGen4Web is an ant build that does the job. I'm currently working
on a new Maven 2 plugin that handles this and it should be finished
by the time you read this. Configuring the test to run as part of
the build will be the tricky (Wendy? help?!?!) part. With this
plugin, you won't have to download the translator.
Like most things in Maven, you aren't forced into a directory
structure, but for this purpose I propose we do this:
struts
+ action
+ apps
+ blank
+ cookbook
+ ...
+ ...
+ TestGen4Web
+ src
+ main
+ scripts <- new (.xml) scripts go here
+ target
+ gensrc <- scripts get gen'd to here (.java)
+ classes <- the plugin would compile the test to here
(Just to be clear, the only thing we should be keeping in svn is the
xml scripts)
This plugin will generate both HttpUnit (.java) and Selenium (.xml)
sources, and this would is where Patrick's process could pick up the
Selenium config.
And so, going forward with this plugin, all we would need to do is
create a new script (e.g. blank-validate-welcome.xml) and put it
under TestGen4Web/src/main/scripts and you are done. Obviously we
would want to be consistent with script naming, personally I would
prefer that they be verbose and in the event that a new script is
needed to verify a specific bug, the bug number might also be in the
name. One other option we might consider is keeping a README.txt in
that directory if any further details are needed.
These scripts would greatly speed up the release process since it
would basically do the equivalent of about 2 or more hours of what
used to be done manually.
However, the fun doesn't stop here. I'm not sure how clear I was in
the chat log about my idea for a linear set of pages to test the
taglibs, but what I had in mind would be to extend the cookbook and
provide many more examples that demonstrate the various ways some
tags can be used.
I'm not sure if we want to go the same route as the taglib tests by
providing a test for every possible combination of attributes for
every tag and some with multiple scenarios for tags that supported
different ways to provide values for a given attribute. Whatever the
case, I'm excited about being able to add new tests that are also
directly adding to the demo apps / tutorials.
When all is said and done, when you do a full build, the tests will
be executed and a report will be generated as part of the site
documentation. But the report part hasn't been written yet.
What do you think?
--
James Mitchell
On Apr 28, 2006, at 6:13 PM, James Mitchell wrote:
Speaking of testing.....I recently came across a really cool plugin
for FireFox. It's called TestGen4Web and it let's you record and
save a browser session.
<feedback type="anticipated">
What the heck is a browser session?
</feedback>
Oh, I'm glad you asked. It is the set of step that you (as a user)
do within a browser window. You can then have the saved session
(which is in xml by the way) converted to an HttpUnit test.
https://addons.mozilla.org/firefox/1385/
--
James Mitchell
On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote:
On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
As for the test cases, I'm not very familiar with Cactus or some
other web app testing packages. So to save time, I've been testing
using a simple web application and clicking through.
...
I can also check my test app into the sandbox if it
will help. Maybe someone can go ahead and start the process of
converting them to Cactus or whatever they need to be.
Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
that each Action 1 example app will at least deploy and display its
default page. If you'll check in the app you mentioned, I'll add a
simple test and you can try it out. Warning: it might require a
little rearranging for Maven 2. :)
Cactus tests are beyond me at this point, I still haven't figured out
why the ones for Struts Taglib don't work.
Thanks,
--
Wendy
---------------------------------------------------------------------
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
Re: Standalone Tiles: Status and Call for Help
Posted by James Mitchell <jm...@apache.org>.
Speaking of testing.....I recently came across a really cool plugin
for FireFox. It's called TestGen4Web and it let's you record and
save a browser session.
<feedback type="anticipated">
What the heck is a browser session?
</feedback>
Oh, I'm glad you asked. It is the set of step that you (as a user)
do within a browser window. You can then have the saved session
(which is in xml by the way) converted to an HttpUnit test.
https://addons.mozilla.org/firefox/1385/
--
James Mitchell
On Apr 28, 2006, at 4:06 PM, Wendy Smoak wrote:
> On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
>
>> As for the test cases, I'm not very familiar with Cactus or some
>> other web app testing packages. So to save time, I've been testing
>> using a simple web application and clicking through.
> ...
>> I can also check my test app into the sandbox if it
>> will help. Maybe someone can go ahead and start the process of
>> converting them to Cactus or whatever they need to be.
>
> Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
> that each Action 1 example app will at least deploy and display its
> default page. If you'll check in the app you mentioned, I'll add a
> simple test and you can try it out. Warning: it might require a
> little rearranging for Maven 2. :)
>
> Cactus tests are beyond me at this point, I still haven't figured out
> why the ones for Struts Taglib don't work.
>
> Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Standalone Tiles: Status and Call for Help
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/21/06, Greg Reddin <gr...@apache.org> wrote:
> As for the test cases, I'm not very familiar with Cactus or some
> other web app testing packages. So to save time, I've been testing
> using a simple web application and clicking through.
...
> I can also check my test app into the sandbox if it
> will help. Maybe someone can go ahead and start the process of
> converting them to Cactus or whatever they need to be.
Craig mentioned HtmlUnit, which we're now using with Cargo to confirm
that each Action 1 example app will at least deploy and display its
default page. If you'll check in the app you mentioned, I'll add a
simple test and you can try it out. Warning: it might require a
little rearranging for Maven 2. :)
Cactus tests are beyond me at this point, I still haven't figured out
why the ones for Struts Taglib don't work.
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Greg Reddin <gr...@apache.org>.
On Mar 22, 2006, at 9:41 AM, Antonio Petrelli wrote:
> It is not an issue anymore because I wrote a workaround in
> Dimensions code. It simply clears the "path" attribute of a
> definition when it's extended (overloaded) when the extended
> definition does not specify the "path" attribute.
> The workaround is not very elegant, I don't know if it deserves a
> Bugzilla ticket, because, maybe, the current one is the desidered
> effect...
That's what I was wondering. I never had a chance to really look at
your solution to determine if the current code is the desired
effect. If you were to post a ticket, it will ensure that this gets
looked at before a release happens. If you don't it may get
overlooked. After looking at the problem again I still don't fully
understand it so I will have to look deeper, in which case it may get
lost again if you don't open a ticket :-)
> I'll try to see if Dimensions can be adapted to the new form of
> Tiles, but I need to investigate deeply. But maybe you can answer a
> question: can I have a different definition for the same definition
> name? That is, if I want to get a definition as an object by giving
> its name, I want to check some circumstances and then decide which
> is the correct definition object to return to the caller. Can I do
> something like this?
My gut feeling is that you might have to extend DefinitionsFactory or
ComponentDefinitions or something like that to make this happen. I
can't say for sure without looking deeper. I would look closely at
ComponentDefinitions and see if it can happen there.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Antonio Petrelli <br...@tariffenet.it>.
Greg Reddin ha scritto:
> Seems a couple of weeks ago you sent an email about a potential bug or
> missing piece. We had a short exchange about it and it fell off my
> radar as I was trying to make sure I understood what your need was.
> It was something about Tiles definitions with extends and path
> attributes. You may have even sent a patch and I was trying to
> determine why it was needed when I lost the thread.
Fortunately I marked the thread as "important" :-P I will repost it at
the end of this mail.
> If it's still an issue for you let me know and we can reopen the
> discussion (probably with a Bugzilla ticket).
It is not an issue anymore because I wrote a workaround in Dimensions
code. It simply clears the "path" attribute of a definition when it's
extended (overloaded) when the extended definition does not specify the
"path" attribute.
The workaround is not very elegant, I don't know if it deserves a
Bugzilla ticket, because, maybe, the current one is the desidered effect...
> Also, if you could let me know if there are places where Standalone
> Tiles is still not viable for Dimensions I'd like to try to address
> those issues.
I'll try to see if Dimensions can be adapted to the new form of Tiles,
but I need to investigate deeply. But maybe you can answer a question:
can I have a different definition for the same definition name? That is,
if I want to get a definition as an object by giving its name, I want to
check some circumstances and then decide which is the correct definition
object to return to the caller. Can I do something like this?
> You're the only one that was extending the original architecture and
> has spoken up about incompatibilities with the new version.
Include Aaron Roller, the first Dimensions developer :-)
> Thanks,
Thanks to you
> Greg
Antonio
------------------------------------------------------------------------------------------
Thread: [Tiles] Definition with extends and path attributes
First mail:
<snip>
Does a definition such as this have sense?
<definition name="myName" extends="myExtends" path="path.jsp">
...
</definition>
This is just because I have a problem with inheritance between multiple
files.
Say I have two files, where the second extends the first.
The first definition file contains:
<definition name="page.index" path="/layout/classic_layout.jsp">
<put name="top" value="/tiles/top.jsp"/>
<put name="left" value="/tiles/fourth.jsp"/>
<put name="body" value="/tiles/login.jsp" />
</definition>
The second file contains:
<definition name="page.index.bug" path="/layout/three_rows_layout.jsp" />
<definition name="page.index" extends="page.index.bug">
<put name="top" value="/tiles/top_pda.jsp"/>
<put name="left" value="/tiles/fourth.jsp"/>
<put name="body" value="/tiles/login.jsp" />
</definition>
When I use XmlDefinitionSet.extend method, the "page.index" definition
has both the "extends" (in fact "inherit") and "path" attributes! After
doing "resolveInheritances" it does not solve the problem.
I think the (possible) bug is in XmlDefinition.overload, where the
attributes are simply copied and not checked.
</snip>
**************
Second mail (by you, i.e. Greg)
<snip>
On Jan 31, 2006, at 8:09 AM, Antonio Petrelli wrote:
> Does a definition such as this have sense?
>
> <definition name="myName" extends="myExtends" path="path.jsp">
I've personally never had a situation like this where I extend a tile
and redefine the path at the same time. I've always extended a tile
definition and overridden only the attributes. But I can see merit to
the approach. If the framework does not currently support it, it
probably should.
> <definition name="page.index" path="/layout/classic_layout.jsp">
> <put name="top" value="/tiles/top.jsp"/>
> <put name="left" value="/tiles/fourth.jsp"/>
> <put name="body" value="/tiles/login.jsp" />
> </definition>
>
>
> The second file contains:
>
> <definition name="page.index.bug"
> path="/layout/three_rows_layout.jsp" />
> <definition name="page.index" extends="page.index.bug">
> <put name="top" value="/tiles/top_pda.jsp"/>
> <put name="left" value="/tiles/fourth.jsp"/>
> <put name="body" value="/tiles/login.jsp" />
> </definition>
To make sure I have this straight: You have "page.index" defined twice
in 2 different files? Why not do something like this?
First file:
<definition name="page.index" path="/layout/classic_layout.jsp">
<put name="top" value="/tiles/top.jsp"/>
<put name="left" value="/tiles/fourth.jsp"/>
<put name="body" value="/tiles/login.jsp" />
</definition>
2nd file:
<definition name="page.index.bug" path="/layout/three_rows_layout.jsp"
extends="page.index" />
Is it a requirement that you always reference "page.index" but get
different definitions in different contexts or can you reference
"page.index.bug" when you want the 3 row layout?
> When I use XmlDefinitionSet.extend method, the "page.index" definition
> has both the "extends" (in fact "inherit") and "path" attributes!
> After doing "resolveInheritances" it does not solve the problem.
> I think the (possible) bug is in XmlDefinition.overload, where the
> attributes are simply copied and not checked.
That's definitely a possibility. Can you verify it?
</snip>
**********************
Third mail (by me) (at the end there is the patch):
<snip>
Greg Reddin ha scritto:
>
> On Jan 31, 2006, at 8:09 AM, Antonio Petrelli wrote:
>
>> Does a definition such as this have sense?
>>
>> <definition name="myName" extends="myExtends" path="path.jsp">
>
> I've personally never had a situation like this where I extend a tile
> and redefine the path at the same time. I've always extended a tile
> definition and overridden only the attributes.
Me too, this is because I asked you this.
> To make sure I have this straight: You have "page.index" defined twice
> in 2 different files?
Right
> Why not do something like this?
> ...
> 2nd file:
> <definition name="page.index.bug" path="/layout/three_rows_layout.jsp"
> extends="page.index" />
>
> Is it a requirement that you always reference "page.index" but get
> different definitions in different contexts or can you reference
> "page.index.bug" when you want the 3 row layout?
I need to use always page.index, because which "page.index" is decided
at runtime. In particular, the "base" page.index is displayed for HTML
devices, the "extended" page.index is displayed for PDAs (as usual I am
referring to Dimensions).
>
>> When I use XmlDefinitionSet.extend method, the "page.index"
>> definition has both the "extends" (in fact "inherit") and "path"
>> attributes! After doing "resolveInheritances" it does not solve the
>> problem.
>> I think the (possible) bug is in XmlDefinition.overload, where the
>> attributes are simply copied and not checked.
>
> That's definitely a possibility. Can you verify it?
In XmlDefinitionsSet.extend I find this code:
<snip>
XmlDefinition childInstance = (XmlDefinition)i.next();
XmlDefinition parentInstance =
getDefinition(childInstance.getName() );
if( parentInstance != null )
{
parentInstance.overload( childInstance );
}
else
putDefinition( childInstance );
</snip>
So, if there is no parent definition, it is simply put, otherwise it is
"overloaded".
The "overload" method is:
<snip>
public void overload( XmlDefinition child )
{
if( child.getPath() != null )
{
path = child.getPath();
}
if( child.getExtends() != null )
{
inherit = child.getExtends();
}
if( child.getRole() != null )
{
role = child.getRole();
}
if( child.getController()!=null )
{
controller = child.getController();
controllerType = child.getControllerType();
}
// put all child attributes in parent.
attributes.putAll( child.getAttributes());
}
}
</snip>
That is, for each property of "child", if it is not null, it is copied,
without modifying the original. IMHO if the "inherit" property of
"child" is not null, the "path" attribute
of the original definition must be set to null (if child.path is null)
or it should match child.path.
So the code could be:
<snip>
public void overload( XmlDefinition child )
{
if( child.getExtends() != null )
{
inherit = child.getExtends();
path = child.getPath(); //It's ok even if it is null
}
else if( child.getPath() != null )
{
path = child.getPath();
}
...
</snip>
Obviously, after all XmlDefinitionsSet.resolveInheritances must be called.
What do you think?
</snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Greg Reddin <gr...@apache.org>.
On Mar 22, 2006, at 2:35 AM, Antonio Petrelli wrote:
> Uh? Who called me? I obviously will be pleased to help if you
> want :-) I could take my experience with Dimensions to add some
> missing pieces.
> Anyway, if I will be so lucky to help you all, notice that I am
> very busy, I can work on it for about 1-2 hour a day.
Seems a couple of weeks ago you sent an email about a potential bug
or missing piece. We had a short exchange about it and it fell off
my radar as I was trying to make sure I understood what your need
was. It was something about Tiles definitions with extends and path
attributes. You may have even sent a patch and I was trying to
determine why it was needed when I lost the thread. If it's still an
issue for you let me know and we can reopen the discussion (probably
with a Bugzilla ticket). Also, if you could let me know if there are
places where Standalone Tiles is still not viable for Dimensions I'd
like to try to address those issues. You're the only one that was
extending the original architecture and has spoken up about
incompatibilities with the new version.
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [OT] Re: Standalone Tiles: Status and Call for Help
Posted by Greg Reddin <gr...@apache.org>.
On Mar 22, 2006, at 8:51 AM, Antonio Petrelli wrote:
> Greg Reddin ha scritto:
>
>>
>> On Mar 22, 2006, at 2:51 AM, Antonio Petrelli wrote:
>>
>>
>>> Antonio Petrelli ha scritto:
>>>
>>>
>>>> I can work on it for about 1-2 hour a day.
>>>>
>>>>
>>> I meant one or two hours a day, not half an hour... It was a bit
>>> ambiguous...
>>>
>>
>> If you have that much time to spend on it then I envy you :-)
>>
> But not on weekends, I would like dedicate those days for nicer
> things than Tiles, my girlfriend for example :-)
+1. For me it's complicated because I'm married to my girlfriend :-)
And there's three little people who think they live here... And, not
only that, but they think I should spend time with *them* on the
weekends :-) What's up with that? And why don't campgrounds have
wireless access yet?
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[OT] Re: Standalone Tiles: Status and Call for Help
Posted by Antonio Petrelli <br...@tariffenet.it>.
Greg Reddin ha scritto:
>
> On Mar 22, 2006, at 2:51 AM, Antonio Petrelli wrote:
>
>> Antonio Petrelli ha scritto:
>>
>>> I can work on it for about 1-2 hour a day.
>>>
>> I meant one or two hours a day, not half an hour... It was a bit
>> ambiguous...
>
> If you have that much time to spend on it then I envy you :-)
But not on weekends, I would like dedicate those days for nicer things
than Tiles, my girlfriend for example :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Greg Reddin <gr...@apache.org>.
On Mar 22, 2006, at 2:51 AM, Antonio Petrelli wrote:
> Antonio Petrelli ha scritto:
>
>> I can work on it for about 1-2 hour a day.
>>
> I meant one or two hours a day, not half an hour... It was a bit
> ambiguous...
If you have that much time to spend on it then I envy you :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Antonio Petrelli <br...@tariffenet.it>.
Antonio Petrelli ha scritto:
> I can work on it for about 1-2 hour a day.
I meant one or two hours a day, not half an hour... It was a bit
ambiguous...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles: Status and Call for Help
Posted by Antonio Petrelli <br...@tariffenet.it>.
Greg Reddin ha scritto:
> In addition I'm sure there are things that have been raised that I
> haven't addressed. especially from Antonio Petrelli.
Uh? Who called me? I obviously will be pleased to help if you want :-) I
could take my experience with Dimensions to add some missing pieces.
Anyway, if I will be so lucky to help you all, notice that I am very
busy, I can work on it for about 1-2 hour a day.
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org