[
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
