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 Martin Cooper <ma...@apache.org> on 2006/11/03 18:05:42 UTC
The health of XAP
I'm growing a little concerned about the health of XAP. Certainly there is
some level of activity, but it all appears to stem from only Nexaweb people.
For example, if we exclude the mentors, none of the non-Nexaweb people from
the original proposal, who are therefore now XAP committers, have shown any
activity at all. The only people who are active are those from Nexaweb; all
of the commits, all of the bug reports, and almost all of the e-mail has
come from them. I could probably count on my fingers the number of other
people I've seen on the mailing list.
Now, don't get me wrong; there's nothing wrong with the Nexaweb folks being
involved. On the contrary, it's good to see that they're still around, and
active and involved. My concern is that we don't seem to be growing any
community around XAP.
It was good to see Bob Buffone give a little spiel on XAP at ApacheCon in
Austin. I'd hoped that that might bring some folks over here to see what's
going on. Sadly, that doesn't seem to have happened.
So, what can we do? How can we attract more attention to XAP, and get more
people involved? Does anyone have any suggestions?
--
Martin Cooper
Re: The health of XAP
Posted by Yoav Shapira <yo...@apache.org>.
Martin et al,
I have no brilliant answers to any of your questions, just +1 to your
concerns (which I also voiced at the time of the original XAP
incubation proposal). I hope things improve,
Yoav
On 11/3/06, Martin Cooper <ma...@apache.org> wrote:
> I'm growing a little concerned about the health of XAP. Certainly there is
> some level of activity, but it all appears to stem from only Nexaweb people.
>
> For example, if we exclude the mentors, none of the non-Nexaweb people from
> the original proposal, who are therefore now XAP committers, have shown any
> activity at all. The only people who are active are those from Nexaweb; all
> of the commits, all of the bug reports, and almost all of the e-mail has
> come from them. I could probably count on my fingers the number of other
> people I've seen on the mailing list.
>
> Now, don't get me wrong; there's nothing wrong with the Nexaweb folks being
> involved. On the contrary, it's good to see that they're still around, and
> active and involved. My concern is that we don't seem to be growing any
> community around XAP.
>
> It was good to see Bob Buffone give a little spiel on XAP at ApacheCon in
> Austin. I'd hoped that that might bring some folks over here to see what's
> going on. Sadly, that doesn't seem to have happened.
>
> So, what can we do? How can we attract more attention to XAP, and get more
> people involved? Does anyone have any suggestions?
>
> --
> Martin Cooper
>
>
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
URL resolution
Posted by James Margaris <jm...@nexaweb.com>.
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: A change to MCO declarations
Posted by Michael Turyn <MT...@nexaweb.com>.
James Margaris writes:
>Sounds good, question:
>
>If I have this:
>
><mco src="com.myCompany.myMco"/>
>
>What happens? We will try to make a new com.myCompany.myMco, that that
doesn't exist will we do a require() on it? To me >that would make the
most sense.
>
>1. IF there is a path, load from that path 2. If there isn't, try a
require on the src
That's the order now. I didn't include a note about the require()
because there seems to be problem with
the paths resolution, or else I put the file in the wrong place. This
wll take future work, but I left
the Xap.require() call is in there as a placeholder.
On paths resolution: I would suggest that the developer be able to alter
and add to the default paths currently set in Xap.js with entries in
XapConfig. Currently, we have
dojo.hostenv.setModulePrefix("dojo", "../dojo/src");
dojo.hostenv.setModulePrefix("xap", "../xap");
dojo.hostenv.setModulePrefix("google", "../google");
...but this ties users to the current directory structure as staged.
A user _could_ alter these or add to them within an html file's
<script/> tag, but that's awkward; I would like to see something like:
<module-maps>
<module-map module-prefix="dojo" module-path="../dojo/src" />
<module-map module-prefix="xap" module-path="../xap" />
<module-map module-prefix="google" module-path="../google" />
<!-- New one -->
<module-map module-prefix="mymcos" module-path="../add_ons/mcos"
/>
</module-maps>
RE: A change to MCO declarations
Posted by James Margaris <jm...@nexaweb.com>.
Sounds good, question:
If I have this:
<mco src="com.myCompany.myMco"/>
What happens? We will try to make a new com.myCompany.myMco, that that
doesn't exist will we do a require() on it? To me that would make the
most sense.
1. IF there is a path, load from that path
2. If there isn't, try a require on the src
James Margaris
-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Tuesday, November 07, 2006 1:12 PM
To: xap-dev@incubator.apache.org
Subject: A change to MCO declarations
A Xal file's mco declarations now can take a "path" attribute in order
to specify source-code for the constructor indicated in 'src', e.g.:
<mco:mco
xmlns:mco="http://www.openxal.org/mco
<http://www.openxal.org/mco> "
id="attributeSetter"
src="AttributeTesterAlias"
path="../widgets/AttributeTester.js"
/>
Why?: It's better that xal pages and even tags be as self-contained as
possible, and in particular a tag that points to an object should be
able to find its definition. This is good in and of itself (for
example, cutting and pasting from an old file into a new one), and
because eventually I'd like to see a simple servlet page that will take
a xal uri as an argument, and embed the xal in an otherwise blank page:
[...]
out.println("<body onload="Xap.createEmbeddedApplications();">") ;
out.println("<div startPage=\"" + request.getParameter("startPage")
+"\"") ;
if(request.getParameter("applicationName") != null
&& request.getParameter("applicationName").length()>0){
out.println(" applicationName=\"" +
request.getParameter("applicationName") +"\"") ;
}
// Any other Xap parameters?:
[...] ;
out.println(">") ;
[...]
(And, of course, the server could be set to do this embedding
automatically for .xal URIs.)
When?:
If the mco "src" doesn't resolve to a valid constructor, we look for a
"path" attribute for the MCO, and if one's found, load from the URI
indicated there (usual restrictions on XmlHttpRequests in mozilla
apply). (We do this in this order so that we don't make too many
requests---we might want to change that behaviour if we should want the
mco to point to dynamic content from a servlet or server page, perhaps
via an "updatable" attribute.)
How?:
A few more blocks of code in McoNamespaceHandler.
A change to MCO declarations
Posted by Michael Turyn <MT...@nexaweb.com>.
A Xal file's mco declarations now can take a "path" attribute in order
to specify source-code for the constructor indicated in 'src', e.g.:
<mco:mco
xmlns:mco="http://www.openxal.org/mco
<http://www.openxal.org/mco> "
id="attributeSetter"
src="AttributeTesterAlias"
path="../widgets/AttributeTester.js"
/>
Why?: It's better that xal pages and even tags be as self-contained as
possible, and in particular a tag that points to an object should be
able to find its definition. This is good in and of itself (for
example, cutting and pasting from an old file into a new one), and
because eventually I'd like to see a simple servlet page that will take
a xal uri as an argument, and embed the xal in an otherwise blank page:
[...]
out.println("<body onload="Xap.createEmbeddedApplications();">") ;
out.println("<div startPage=\"" + request.getParameter("startPage")
+"\"") ;
if(request.getParameter("applicationName") != null
&& request.getParameter("applicationName").length()>0){
out.println(" applicationName=\"" +
request.getParameter("applicationName") +"\"") ;
}
// Any other Xap parameters?:
[...] ;
out.println(">") ;
[...]
(And, of course, the server could be set to do this embedding
automatically for .xal URIs.)
When?:
If the mco "src" doesn't resolve to a valid constructor, we look for a
"path" attribute for the MCO, and if one's found, load from the URI
indicated there (usual restrictions on XmlHttpRequests in mozilla
apply). (We do this in this order so that we don't make too many
requests---we might want to change that behaviour if we should want the
mco to point to dynamic content from a servlet or server page, perhaps
via an "updatable" attribute.)
How?:
A few more blocks of code in McoNamespaceHandler.
RE: A change to require()?
Posted by James Margaris <jm...@nexaweb.com>.
Sounds good to me, supressing errors that can create weird application
behaviors is not a good thing.
-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Tuesday, November 07, 2006 11:56 AM
To: xap-dev@incubator.apache.org
Subject: A change to require()?
Currently, Xap.require() won't throw an error if there's an underlying
problem loading a class. Would anyone object to my altering Xap such
that it will in that case (currently, iff dojo.require() throws an
exception)?
It might induce errors showing up, but I, for one, welcome knowing about
them.
(In the mean-time, I'm making the method return a boolean based on
success; that will affect no-one else.)
A change to require()?
Posted by Michael Turyn <MT...@nexaweb.com>.
Currently, Xap.require() won't throw an error if there's an underlying
problem loading a class. Would anyone object to my altering Xap such
that it will in that case (currently, iff dojo.require() throws an
exception)?
It might induce errors showing up, but I, for one, welcome knowing about
them.
(In the mean-time, I'm making the method return a boolean based on
success; that will affect no-one else.)
Re: The health of XAP
Posted by robert burrell donkin <ro...@gmail.com>.
On 11/5/06, Coach Wei <co...@nexaweb.com> wrote:
<snip>
> There is an obvious need and interest for XAP as I have heard such from
> a lot of conversations and customer needs. Declarative Ajax is validated
> by various proprietary software offerings (such as Microsoft Altas);
perhaps that would make an interesting article for oreilly or
theserverside (XAP as an open source java analogue for atlas)
> However, XAP lacks some elements required to engage a community:
> 1. How many people have heard of XAP? Not that many. There are some and
> I personally know quite a few are fairly interested in digging into it -
> however...
> 2. XAP has no engaging demo or samples, nor text description, to get
> someone to be further his interest;
> 3. Getting the XAP code and start to write an app? Or even digging into
> the code? Hard, very hard, even for me;
>
> The above are my observations. To a large degree, they are natural for a
> project at this stage - which is why I said we should not be overly
> concerned about the situation at the moment.
but it's probably a good time to start working towards raising XAP's profile
> Going forward, I think Bob Buffone made some really good suggestions
> that would certainly help. In particular, I think XAP needs:
> 1. Some good demo or sample applications that pick an visitor's
> interest;
> 2. Some straightforward documentation to help them get started with
> building sample code or apps;
>
> These are things that some committers are trying to work on over the
> next few months.
>
> Lastly, I want to caution other Apache folks though - there is not
> overnight success. It will take a lot of work and probably many more
> months for us to see a growing community.
+1
community building is more art than science
momentum is somewhat unponderable and unfathomable
- robert
RE: The health of XAP
Posted by Coach Wei <co...@nexaweb.com>.
I share your concern and, actually, I have had discussions on this
subject with XAP mentors and quite a few other people inside/outside of
the Apache Community a few times over the last few months.
On the flip side, I am less concerned about it after talking to the
various folks. I think there are good reasons to be not too concerned
about it too.
As we all know well, it is not easy to build a community. A community
get built and established for the following factors:
1. There is a need and interest for what the Project does;
2. People get to hear about or get to know about the project as a
potential solution to their needs;
3. Once people hear about the project, some of them will try to check it
out - typically starting by taking a look at demos or reading some
quick/short materials to see whether it is worthy of further
investigation or not;
4. If it deems worthy of further investigation, they will probably get
hold of the code and try to dig in;
5. As a result of digging in, they may build some sample
apps...eventually, starting to find bugs and fix code...
There is an obvious need and interest for XAP as I have heard such from
a lot of conversations and customer needs. Declarative Ajax is validated
by various proprietary software offerings (such as Microsoft Altas);
However, XAP lacks some elements required to engage a community:
1. How many people have heard of XAP? Not that many. There are some and
I personally know quite a few are fairly interested in digging into it -
however...
2. XAP has no engaging demo or samples, nor text description, to get
someone to be further his interest;
3. Getting the XAP code and start to write an app? Or even digging into
the code? Hard, very hard, even for me;
The above are my observations. To a large degree, they are natural for a
project at this stage - which is why I said we should not be overly
concerned about the situation at the moment.
Going forward, I think Bob Buffone made some really good suggestions
that would certainly help. In particular, I think XAP needs:
1. Some good demo or sample applications that pick an visitor's
interest;
2. Some straightforward documentation to help them get started with
building sample code or apps;
These are things that some committers are trying to work on over the
next few months.
Lastly, I want to caution other Apache folks though - there is not
overnight success. It will take a lot of work and probably many more
months for us to see a growing community.
> -----Original Message-----
> From: Bob Buffone [mailto:rbuffone@nexaweb.com]
> Sent: Saturday, November 04, 2006 4:02 PM
> To: xap-dev@incubator.apache.org
> Subject: RE: The health of XAP
>
> As a committer and a person who likes everything that I am committed
to
> doing, to be a success, I understand your concerns.
>
> XAP is a relatively young project even from the stand point of Apache.
> The initial code for the project was only the basic foundation of what
> was needed to in order for others to make use of XAP in their projects
> and work. Over the last 5 months the committers have been working
heads
> down on making the code useful to the population at large. We are
just
> starting to see the work payoff and will be doing more in the way of
> getting people started with the project.
>
> I, as you would like to see more outside (of Nexaweb) people
> contributing to the project. It would be great to collaborate with
> others on the project.
>
> Things that I think we (XAP) can do make XAP accessible and visible:
>
> 1.) Utilize other Apache projects in XAP and also contribute
> enhancements to existing Apache project with XAP functionality. Apache
> as a whole has a great number of resources and people to draw from; it
> would be nice if they were involved.
> 2.) We need to make sure that we can make it easy for people to start
> using XAP in their projects. If others don't see XAP as beneficial to
> them, they are less likely to get involved. We have seen some people
> start using XAP and I have been talking about it every chance I get.
> 3.) Get some 3rdparty visible applications built on the project.
> Showcase it benefits.
> 4.) More public communication between XAP committers via the mailing
> list.
>
> If anyone else has suggestions, please offer them up, I look forward
to
> hear them.
>
> Bob (Buffone)
>
> -----Original Message-----
> From: mfncooper@gmail.com [mailto:mfncooper@gmail.com] On Behalf Of
> Martin Cooper
> Sent: Friday, November 03, 2006 1:06 PM
> To: xap-dev@incubator.apache.org
> Subject: The health of XAP
>
> I'm growing a little concerned about the health of XAP. Certainly
there
> is
> some level of activity, but it all appears to stem from only Nexaweb
> people.
>
> For example, if we exclude the mentors, none of the non-Nexaweb people
> from
> the original proposal, who are therefore now XAP committers, have
shown
> any
> activity at all. The only people who are active are those from
Nexaweb;
> all
> of the commits, all of the bug reports, and almost all of the e-mail
has
> come from them. I could probably count on my fingers the number of
other
> people I've seen on the mailing list.
>
> Now, don't get me wrong; there's nothing wrong with the Nexaweb folks
> being
> involved. On the contrary, it's good to see that they're still around,
> and
> active and involved. My concern is that we don't seem to be growing
any
> community around XAP.
>
> It was good to see Bob Buffone give a little spiel on XAP at ApacheCon
> in
> Austin. I'd hoped that that might bring some folks over here to see
> what's
> going on. Sadly, that doesn't seem to have happened.
>
> So, what can we do? How can we attract more attention to XAP, and get
> more
> people involved? Does anyone have any suggestions?
>
> --
> Martin Cooper
RE: The health of XAP
Posted by Bob Buffone <rb...@nexaweb.com>.
As a committer and a person who likes everything that I am committed to
doing, to be a success, I understand your concerns.
XAP is a relatively young project even from the stand point of Apache.
The initial code for the project was only the basic foundation of what
was needed to in order for others to make use of XAP in their projects
and work. Over the last 5 months the committers have been working heads
down on making the code useful to the population at large. We are just
starting to see the work payoff and will be doing more in the way of
getting people started with the project.
I, as you would like to see more outside (of Nexaweb) people
contributing to the project. It would be great to collaborate with
others on the project.
Things that I think we (XAP) can do make XAP accessible and visible:
1.) Utilize other Apache projects in XAP and also contribute
enhancements to existing Apache project with XAP functionality. Apache
as a whole has a great number of resources and people to draw from; it
would be nice if they were involved.
2.) We need to make sure that we can make it easy for people to start
using XAP in their projects. If others don't see XAP as beneficial to
them, they are less likely to get involved. We have seen some people
start using XAP and I have been talking about it every chance I get.
3.) Get some 3rdparty visible applications built on the project.
Showcase it benefits.
4.) More public communication between XAP committers via the mailing
list.
If anyone else has suggestions, please offer them up, I look forward to
hear them.
Bob (Buffone)
-----Original Message-----
From: mfncooper@gmail.com [mailto:mfncooper@gmail.com] On Behalf Of
Martin Cooper
Sent: Friday, November 03, 2006 1:06 PM
To: xap-dev@incubator.apache.org
Subject: The health of XAP
I'm growing a little concerned about the health of XAP. Certainly there
is
some level of activity, but it all appears to stem from only Nexaweb
people.
For example, if we exclude the mentors, none of the non-Nexaweb people
from
the original proposal, who are therefore now XAP committers, have shown
any
activity at all. The only people who are active are those from Nexaweb;
all
of the commits, all of the bug reports, and almost all of the e-mail has
come from them. I could probably count on my fingers the number of other
people I've seen on the mailing list.
Now, don't get me wrong; there's nothing wrong with the Nexaweb folks
being
involved. On the contrary, it's good to see that they're still around,
and
active and involved. My concern is that we don't seem to be growing any
community around XAP.
It was good to see Bob Buffone give a little spiel on XAP at ApacheCon
in
Austin. I'd hoped that that might bring some folks over here to see
what's
going on. Sadly, that doesn't seem to have happened.
So, what can we do? How can we attract more attention to XAP, and get
more
people involved? Does anyone have any suggestions?
--
Martin Cooper