[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[atf-dev] Re: atf-dev Digest, Vol 2, Issue 15

Hi Jesse.  I'm not too knowledgeable on Project structure, so maybe
someone else can help me out.

-) Noticed that running an html file as a "mozilla" app or even trying to
create a new run config as a mozilla app was causing numerous issues if I
don't have my directory layout structured exactly as it wants. (presumably
webContent or other ?)

We are built on top of the Eclipse WebTools Project (WTP) and leverage what they call "dynamic web projects" to do our server deployment. The WebContent directory you see is part of the definition of a dynamic web project, and Dojo and other "personalities" basically extend this by using natures (Eclipse-speak for behavior on a project) We haven't done a whole lot of integration with other types of Eclipse projects, so we may not be complete in this area, but so long as you are working from a dynamic web project, you should be okay. You might need to have this nature in your project, and I'm not sure there's any way to get it currently except to create a new dynamic web project?

I have no idea if the mozilla app type will even be something I should be
using

Yep. It's not entirely clear, but that's basically the launch type responsible for first deploying your code on the server, then launching the html file in an embedded Mozilla browser. It's a trigger for Eclipse to launch Mozilla, and one will be created for you if you do a right click on an .html file + "Run in Mozilla". Or, you can make one from the launcher dialog.

but after having done some recent research into java XPCOM (can only
assume you guys did this wrapper as well?)

Yep. Javier on our team built the bridge and gave it back to Mozilla.org. It gets pulled in during install.

I was beginning to wonder if you
hadn't solved the problem of in-browser unit tests without the browser
already ?

Unit tests are on our todo list, but we have not tacked this yet. We are hoping to implement automation for jsunit, but were also thinking about using XPCOM to do some browser automation. I'm not sure if you can do this without a visible browser instance, however? Is that what you mean?

That seems like the largest barrier to having what would be considered a
"pretty complete" set of testing abilities...You still can't test that
visually things appear exactly(or relatively) here and here on an html page
(or maybe you can? cringe...) but you can at least have all of your normal
window/ events happening...Is this a pipe dream?

Well, if the browser were visible, presumably you could use getComputedStyle and other DOM accessors to look for elements and their position? I'm not sure I totally follow the question.

-) Looks like there is starting to be a lot of great support for doing
various things in here, without anyone having to type too much or try to
make it too "official" is there a rough idea of what kind of capabilities
might be expected to come out of the project? (or...rtfm may be the answer
if it was already outlined in the eclipse proposal...ui'll try that next.)

No, we need to work on getting some documentation out. Our apologies. Recommendations (and contributions :-) are gladly accepted.

I have a project dojo / custom js package layout looking something like
this:
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/framework/src/js/

Personalities won't help you much in their present state -- all they really do today is help layout new projects. Perhaps you could just put all this content in a dynamic web project and use subversion directly? (Unsure if it's possible to check stuff out into WebContent or use symlinks to put them there w/o restructuring your svn) We don't know how to span multiple projects, so anything you build with these Dojo libraries would have to be included in the same project today... Tracking code across multiple projects is another thing for the todo list...

Regards,
Adam