You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xap-dev@incubator.apache.org by James Margaris <jm...@nexaweb.com> on 2006/11/06 08:55:10 UTC
URL resolution
Here is an interesting problem I am running into.
Say I have a servlet called "MyServlet". I am running xap out of a web application called "MyApplication".
From code I want to send something to "MyServlet". What URL do I use?
In an html browser "/" is typically relative to the server URL. So if I do "/MyServlet" it will not resolve to http://localhost/MyApplication/MyServlet but instead http://localhost/MyServlet, which is not correct in this case.
I could make the request to /MyApplication/MyServlet, but that means my client-side code needs to know the name of the webapp.
Alternately we could expose the name of the webapp context and my code would append "MyServlet" to that.
From a J2EE web-application perspective typically you are not hitting pages on the server outside of the webapp, although it certainly is possible.
Note that this is an even more annoying problem if you have XML code like:
onCommand="/MyServlet?a=b"
In this case if I want to hit MyApplication/MyServlet I really have to hardcode that in the XML.
Possible solutions:
1: Leave it alone, they can hardcode in XML and append their URL to the context path in code.
2: Have at least optionally a flag or something like that that maps "/" to the root of the web application instead of the server root.
Ideas?
James Margaris
Zimbra b-gone
Posted by James Margaris <jm...@nexaweb.com>.
I have removed all (hopefully) remnants of Zimbra support from the
trunk, including all the Zimbra based samples. (Which had not worked in
some time)
If at some point we want to make a serious effort to support Zimbra that
code is in SVN history or the first tag.
There shouldn't be much difference that anyone can see, other than less
code in the src directory to make things more manageable, none of the
zimbra source or the bridges/components had been in use for some time.
James Margaris
RE: URL resolution
Posted by James Margaris <jm...@nexaweb.com>.
Meh, ignore this, it doesn't make any sense the more I think about it. I
will formulate a more thought-out proposal at some point.
James Margaris
-----Original Message-----
From: James Margaris [mailto:jmargaris@nexaweb.com]
Sent: Tuesday, November 07, 2006 5:50 PM
To: xap-dev@incubator.apache.org
Subject: RE: URL resolution
I think I've been overthinking this a bit. I got hung up on some issues
like where do you load a .xal file from and how do the URLs relate to
that.
I think the best thing here is to make URLs relative to whatever the
browser URL is, and provide an optional "base URL" equivalent in the
starting xal file. So it doesn't matter where you xal file or xmodify
was loaded from, all that matters the browser URL or base url.
Sound reasonable?
From code it would work the same, where requesting in code something
like "../mypage" would request that relative to the current browser URL
and nothing more.
That is certainly understandable and is also light on required
processing.
James Margaris
Re:RE: More on styling
Posted by Michael Turyn <MT...@nexaweb.com>.
I got you beat James: another victim of the "hit reply to random message
without thinking that much," meme.
I forgot that .css stylesheets weren't replaced by .xml---change that
question to one about the value of building a class to transform Xap's
styles to Dojo's.
-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Friday, November 10, 2006 11:17 AM
To: xap-dev@incubator.apache.org
Subject: RE: More on styling
Would it be possible to use an XSL transform to map from our classes to
Dojo's?
RE: More on styling
Posted by Michael Turyn <MT...@nexaweb.com>.
Would it be possible to use an XSL transform to map from our classes to
Dojo's?
More on styling
Posted by James Margaris <jm...@nexaweb.com>.
So the styling stuff works well with our buttons and labels and things like that. I said I would look into Dojo and that is a bit more complicated.
Dojo widgets already have their own classnames. Some of these get pretty specific, for example changing the left and right border images on a tab in a tab container. I don't think it is worth the time and effort to try to rename these classes or change the scheme around. So when we make a tabPane we can give a class "xapTabPane" but it will also have a bunch of dojo classes on it.
One annoying thing about this is that there is no unified stylesheet for the dojo stuff, to figure out what each class is you have to experiment and look at each individual template file for each widget.
It is also going to be difficult to do something like have a different color when you roll over a tab, but no harder than it is to do in dojo normally.
Messing with the Dojo toolkit widgets a lot is probably not something we want to do, especially given that .4 has come out and we will want to upgrade to that (and beyond) at some point. My personal opinion is that in the long run it would be better to simply not use the Dojo widgets. They don't play well with other components and have some issues in general. (Touchy about size, image based looks that are hard to customize, etc) The base classes and general strategy for creating widgets is excellent but the end-user widgets themselves are merely average. (Again my opinion)
So the bottom line is that the states along with the formula based names are working well for components that we have mostly implemented, but not so well for components derived heavily from dojo widgets including window, tabPane, splitPane and menu stuff.
One thing we may want to do is pull the dojo classes out of the individual template CSS files that are most useful to end users and stick them in our general stylesheet, along with some different defaults possibly.
James Margaris
enabled -> disabled
Posted by James Margaris <jm...@nexaweb.com>.
To be more in line with HTML I am reversing this attribute. Changing all the samples, bridge classes, etc. I am not changin the internal representation of the peer classes, they may still track disabled/enabled with a variable named "enabled" but the attribute will always be "disabled" as will the style name.
James Margaris
RE: Table stuff
Posted by James Margaris <jm...@nexaweb.com>.
Awesome, another victim of the "hit reply to random message in mailbox without paying attention to sender."
So yeah...I was planning on doing some work on tree/treeTable but got stuck on label/button bugs. :)
James Margaris
________________________________
From: James Margaris [mailto:jmargaris@nexaweb.com]
Sent: Thu 11/9/2006 11:03 PM
To: xap-dev@incubator.apache.org
Subject: Table stuff
If you still have text/window/comboBox bugs it might be better to work on those and get to tree/treeTable on Monday. I was going to do a fair amount of work on tree/treeTable today but got bogged down in style stuff and some label/button bugs.
James
Table stuff
Posted by James Margaris <jm...@nexaweb.com>.
If you still have text/window/comboBox bugs it might be better to work on those and get to tree/treeTable on Monday. I was going to do a fair amount of work on tree/treeTable today but got bogged down in style stuff and some label/button bugs.
James
RE: A whole bunch of cosmetic improvements
Posted by James Margaris <jm...@nexaweb.com>.
I'm not quite sure what you are asking. The .css page is included in the HTML file, if they want to override those they can change the CSS or include a new one after that one. The only difference between our "official" stylesheet and any other is that our is included by the html pages in the samples.
________________________________
From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Thu 11/9/2006 5:22 PM
To: xap-dev@incubator.apache.org
Subject: RE: A whole bunch of cosmetic improvements
Very good. If the html page loading the xal has preloaded a local
sheet, does it overwrite default values?
RE: A whole bunch of cosmetic improvements
Posted by Michael Turyn <MT...@nexaweb.com>.
Very good. If the html page loading the xal has preloaded a local
sheet, does it overwrite default values?
A whole bunch of cosmetic improvements
Posted by James Margaris <jm...@nexaweb.com>.
(Apologies for poorly formatted HTML message, mail reader is not well configurable)
I am spending some time on the stylesheet, but more importantly making the stylesheet more useful. I think I have a pretty good scheme for attaching style information:
1: For each component created, it is assigned a class name. This class name is based on some formula, like "xap" + the name of the element capitalized. ("xapButton", "xapTreeTable", etc)
2: In addition, when the component changes state a new class is added/remove. That class is of the form CLASS_NAME + STATE_NAME. For example:
"xapButtonMouseDown"
3: The states are:
MouseDown
MouseOver
Focused
Disabled
All of this is handled by the base AbstractWidgetBridge so not many changes are required. An example css entry for button:
.xapButton{
border-top : 2px outset #ccc;
border-right: 2px outset #ccc;
border-bottom: 2px outset #ccc;
border-left: 2px outset #ccc;
padding: 2px 2px 2px 2px;
}
.xapButtonMouseOver{
background-color: #EEEEFF;
color:orange;
}
.xapButtonMouseDown{
border-top : 2px inset #ccc;
border-right: 2px inset #ccc;
border-bottom: 2px inset #ccc;
border-left: 2px inset #ccc;
padding: 4px 0px 0px 4px;
}
.xapButtonDisabled{
color : gray;
border-top : 2px solid gray;
border-right: 2px solid gray;
border-bottom: 2px solid gray;
border-left: 2px solid gray;
}
This is very flexible and nice, some highlights:
Disabled buttons are grey.
When you press a button the content shifts down and to the right and the border changes to inset.
Rolling over a button turns it blue with orange text. (Graphic designer I am not)
I will check in a stylesheet with some entires for a couple of key components along with the general scheme. One thing I need to determine is how to make this play well with dojo components that define their own class names already, including on divs etc nested inside the component.
James Margaris
Insert at an index working again
Posted by James Margaris <jm...@nexaweb.com>.
As you may recall, I broke this a while ago when I switched the
components to hook up to each other from parent to child instead of
backwards from child to parent. (The idea was that child to parent is
probably more efficient overall but just doesn't work well in HTML for a
variety of reasons, including sizing issues)
That should be working again. It may not work for each individual
component (for example inserting rows in a table at an index) but it
should be passed around correctly, the general scheme is in place and it
works for verticalPanel.
James Margaris
RE: URL resolution
Posted by James Margaris <jm...@nexaweb.com>.
Ok, a better attempt to explain the problem:
The problem (not exact xml):
Start page:
<freePanel id="myPanel">
<button onCommand="xmodify/xmodify1.xml"/>
</freePanel>
xmodify/xmodify1.xml:
<append-child select="id('freePanel')">
<button img="myImage.gif" onCommand="myPage.jsp"/>
</append-child>
When I click on the button and load xmodify1.xml to get a second button,
where does the .gif on that second button come from, and where does the
onCommand point to?
Answer 1:
myImage.gif and myPage.jsp are both relative to the application start
page.
Reasoning: My web browser URL has not changed, and these should be
relative to the web-browser URL.
Issues: In my original onCommand I went into a folder, shouldn't the
page loaded one-level deeper reflect that in the URL resolution? Note
that if this were an HTML application and the onCommand was an href the
urls would be relative to the "xmodify" directory.
Answer 2:
myImage.gif and myPage.jsp are both relative to the xmodify directory.
Reasoning: That is where the xmodify1.xml page was served from, and
where I pointed to in my onCommand. Again note that if this were an HTML
application and the onCommand was an href the urls would be relative to
the "xmodify" directory. (As they are now)
Issues: I haven't actually moved pages, my browser URL is still the
same.
----
The trickyness here is that asynch updating is not a page based model.
In the case above I am loading new content but not swapping pages. If I
have a lot of content and start organizing into folders the URL
resolution becomes tricky.
Without getting into technical pros and cons or anything like that, what
answer makes more sense to people? It is really a judgement call.
My opinion would be that answer 2 makes more sense. If in your
client-side XML you point to a directory the stuff fed out from that
directory should be interpreted as relative to that directory.
James Margaris
RE: URL resolution
Posted by James Margaris <jm...@nexaweb.com>.
I think I've been overthinking this a bit. I got hung up on some issues
like where do you load a .xal file from and how do the URLs relate to
that.
I think the best thing here is to make URLs relative to whatever the
browser URL is, and provide an optional "base URL" equivalent in the
starting xal file. So it doesn't matter where you xal file or xmodify
was loaded from, all that matters the browser URL or base url.
Sound reasonable?
From code it would work the same, where requesting in code something
like "../mypage" would request that relative to the current browser URL
and nothing more.
That is certainly understandable and is also light on required
processing.
James Margaris
Debugging changes
Posted by Michael Turyn <MT...@nexaweb.com>.
Debugging has been changed to fit in with the new startup.
Background: to be visible under Venkman, the Mozilla debugging
interface, JS objects have to be loaded using <script/> tags, rather
than the fetch/eval mechanism we've adopted from Dojo (for good
reasons); our debugging mechanism accomplishes this by going from a
class name to a file path, and writing the appropriate script tag.
(Dojo can do this too, supposedly, but making it work seemed impossible;
also, it can only do all-or-nothing debugging, and I think
class-by-class granularity will be useful.)
Most of the changes are refactoring: Bob Buffone has removed the
debugging machinery from Xap and put it into a new xap.util.Debug class,
which I've adapted for ease-of-use. In order to run debugging, you must
add a "debug_config" object to the JS global scope _before_ loading
xapcore.js. You may either specify a list of classes
<script language="JavaScript">
// Debug chosen classes
debug_config = {
_debugList:[
"xap.widgets.dojo.ListBox",
"xap.bridges.xap.XapComboBoxBridge",
"xap.bridges.xap.ListBoxBridge",
"xap.bridges.dojo.DojoWidgetBridge"
] } ;
</script>
...or prep all classes for debugger-friendly loading:
<script language="JavaScript">
// Debug all classes loaded
debug_config = {_debugAll: true} ;
</script>
Then, after xapcopre.js is loaded but before the end of the <head/>
portion of html, you'll need to add the actual load command:
<script language="JavaScript">
<!-- must do this before we load the actual application: -->
xap.util.Debug.loadDebuggables() ;
</script>
Early on in developing a new feature or debugging an old one, "debugAll"
probably makes sense. When you've just got a few classes that will need
changing, specifying them makes more sense since that's closer to the
deployment version.
Added bonus: because the individual files will be loaded after
xapcore.js, their code overwrite its code. This has three useful
consequences:
1.) The code the debugger will show for them loads much faster
than the whole xapcore.js,
2.) The code will not be compactified, so it will have much more
meaningful variable names (except, prehaps, for some of my code)
and
3.) If you're developing a class that will be debug-loaded, you
can test the new code by rerunning your test page after just copying
over that class file---no need to go through the entire build process.
(Under Windows, xcopy /s/D under is useful for this.)
Caveat: If you make a file available via the debugging mechanism, you
should test your code without debugging before you check it in. Why?:
a subsequent developer might want to turn debugging off, at which point
you could get exceptions when it turns out that other files that should
load the file with Xap.require() are missing that declaration.
(You can also include a _sourceRootDir member in debug_config; if you
don't, it will default to "../../src", which works for our examples.
The mechanism for adding the <script/> tag is in the Debug class itself,
decoupling it from the equivalent mechanism in Utils, for which the
"src" was implied.)
RE: URL resolution
Posted by James Margaris <jm...@nexaweb.com>.
That is true, it is mostly a code issue. In code if you do something
like:
getNetService().retrieve("MyServlet")
We don't remember where the code was loaded from or do any path
manipulation like that. In XML it makes sense to remember where the XML
was loaded from and allow it to be relative, in code we can't really do
that.
In code right now you have to do something like:
getNetService().retrieve(session._webappContext + "MyServlet");
It is kind of ugly by manageable I suppose. (We could clean up the
variable name and such.
James Margaris
-----Original Message-----
From: Coach Wei [mailto:coach@nexaweb.com]
Sent: Monday, November 06, 2006 10:31 AM
To: xap-dev@incubator.apache.org
Subject: RE: URL resolution
Why can't you just do something like onCommand="MyServlet?a=b"?
If the page is loaded from "MyApplication" webapps, any relative URL
should resolve to this webapp. In HTML, for example, if page1.html is
loaded from "/MyApp", any relative URL that page1.html uses would be
resolved to "/MyApp/relativeURL". I would we preserve this pattern.
I do see one potential problem: If a page is loaded from "/MyApp/Pages",
then a relative URL such as "MyServlet" should be resolved to
"/MyApp/Pages/MyServlet" - which is clearly a problem. However, in this
case, the developer should reference to "MyServlet" via "../MyServlet"
instead.
So my recommendation is to keep track of the URL of the page, and any
relative URL in this page should be resolved relatively to the page URL;
unless the URL is hardcoded to something else.
> -----Original Message-----
> From: James Margaris [mailto:jmargaris@nexaweb.com]
> Sent: Monday, November 06, 2006 3:55 AM
> To: xap-dev@incubator.apache.org
> Subject: URL resolution
>
> Here is an interesting problem I am running into.
>
> Say I have a servlet called "MyServlet". I am running xap out of a web
> application called "MyApplication".
>
> From code I want to send something to "MyServlet". What URL do I use?
>
> In an html browser "/" is typically relative to the server URL. So if
I do
> "/MyServlet" it will not resolve to
> http://localhost/MyApplication/MyServlet but instead
> http://localhost/MyServlet, which is not correct in this case.
>
> I could make the request to /MyApplication/MyServlet, but that means
my
> client-side code needs to know the name of the webapp.
>
> Alternately we could expose the name of the webapp context and my code
> would append "MyServlet" to that.
>
> From a J2EE web-application perspective typically you are not hitting
> pages on the server outside of the webapp, although it certainly is
> possible.
>
> Note that this is an even more annoying problem if you have XML code
like:
>
> onCommand="/MyServlet?a=b"
>
> In this case if I want to hit MyApplication/MyServlet I really have to
> hardcode that in the XML.
>
> Possible solutions:
>
> 1: Leave it alone, they can hardcode in XML and append their URL to
the
> context path in code.
>
> 2: Have at least optionally a flag or something like that that maps
"/" to
> the root of the web application instead of the server root.
>
> Ideas?
>
> James Margaris
RE: URL resolution
Posted by Coach Wei <co...@nexaweb.com>.
Why can't you just do something like onCommand="MyServlet?a=b"?
If the page is loaded from "MyApplication" webapps, any relative URL
should resolve to this webapp. In HTML, for example, if page1.html is
loaded from "/MyApp", any relative URL that page1.html uses would be
resolved to "/MyApp/relativeURL". I would we preserve this pattern.
I do see one potential problem: If a page is loaded from "/MyApp/Pages",
then a relative URL such as "MyServlet" should be resolved to
"/MyApp/Pages/MyServlet" - which is clearly a problem. However, in this
case, the developer should reference to "MyServlet" via "../MyServlet"
instead.
So my recommendation is to keep track of the URL of the page, and any
relative URL in this page should be resolved relatively to the page URL;
unless the URL is hardcoded to something else.
> -----Original Message-----
> From: James Margaris [mailto:jmargaris@nexaweb.com]
> Sent: Monday, November 06, 2006 3:55 AM
> To: xap-dev@incubator.apache.org
> Subject: URL resolution
>
> Here is an interesting problem I am running into.
>
> Say I have a servlet called "MyServlet". I am running xap out of a web
> application called "MyApplication".
>
> From code I want to send something to "MyServlet". What URL do I use?
>
> In an html browser "/" is typically relative to the server URL. So if
I do
> "/MyServlet" it will not resolve to
> http://localhost/MyApplication/MyServlet but instead
> http://localhost/MyServlet, which is not correct in this case.
>
> I could make the request to /MyApplication/MyServlet, but that means
my
> client-side code needs to know the name of the webapp.
>
> Alternately we could expose the name of the webapp context and my code
> would append "MyServlet" to that.
>
> From a J2EE web-application perspective typically you are not hitting
> pages on the server outside of the webapp, although it certainly is
> possible.
>
> Note that this is an even more annoying problem if you have XML code
like:
>
> onCommand="/MyServlet?a=b"
>
> In this case if I want to hit MyApplication/MyServlet I really have to
> hardcode that in the XML.
>
> Possible solutions:
>
> 1: Leave it alone, they can hardcode in XML and append their URL to
the
> context path in code.
>
> 2: Have at least optionally a flag or something like that that maps
"/" to
> the root of the web application instead of the server root.
>
> Ideas?
>
> James Margaris