To edit or add content to this Wiki, you can simply create a new account at http://wocommunity.org/account.
At the very least, it would be nice to be able to launch my projects in the debugger and not have to set the class path each time I hit a breakpoint to view the source. But it's a minor inconvenience.
A one click Java Web Start installer. Just click on a hyperlinked .jnlp file and Java web start downloads the installer which then would install Eclipse, WOLips, WO 5.4.3, jadclipse, jad, latest svn, subclipse, Wonder 54 branch, WO javadocs, set up a new workspace complete with working sets for Wonder frameworks, examples, applications, and tests. 'Advanced' options could be offered, including apache/monitor/wotaskd installation and setup.
Must check installer from Ken Ishimoto.
A fixed Direct To Web JavaApplet should be reinstated as a simple way to configure a DirectToWeb app. Rule Modeler is OK for advanced rulemodeling, but is too complicated for beginners with DirectToWeb.
Perhaps inline forms would be easier than an applet. For example, right now, if you hit the D2W link on the debug panel, you see tables at the page level and on property names. Perhaps it would be easy enough to simply provide a form + table instead of just a table. Then you could select the component name from a popup menu or add/remove displayPropertyKeys from the page level form.
We should have a system that auto-patch Wonder on another server, so that we can see if the patches compiles fine and do basic testing to see if it's broken. If it works, we can commit the patch in Wonder.
We should override all WO components and EOF calls in Wonder, so that it could be easier to move to another implementation. For example, we could later decide that instead of using EOF, we would use Cayenne, but by using calls from Wonder, the APIs in Wonder would talk to Cayenne instead of EOF.
We need a REST client in ERRest so that we can easily call REST APIs from other sources, and convert the results to EOs if required. A sort of client exists in the RestRoute example, and other code based on Jakarta httpclient was posted on the mailing list. We could take a look at Jersey and JBoss' RestEasy too.
We need unit/Selenium tests in Wonder for core stuff. Examples : doing fetchs with dates, testing prototypes on MySQL, PostgreSQL, H2 and FrontBase, core Ajax functionnality, etc. Those tests would be useful to test patches
Since many WO developers also develop iOS or Mac apps, it would be useful to have better integration between WO and Cocoa/CocoaTouch. One idea would be to generate a Xcode project stub based of an EOModel and REST route, the Xcode project stub would have the necessary code to make REST calls to the WO app.
Excellent support for iOS REST backends
an example of integrating WebObjects with iOS, how to communicate from the iPhone app to the WebObjects backend.
I'd like to see a way to keep CoreData models and EO models in sync. Also a D2Rest from CoreData would be pretty cool.
Wonder source has accumulated many TODO and FIXME comments that should be reviewed if they
a) are obsolete
b) need code to be fixed/tested
c) should have a JIRA created for to be fixed in the near future
Wonder code has been committed by many different people and all those people have different formatting preferences. By defining a general eclipse formatter the code would be cleaner and committing patches would (in the end) only show real code changes and no formatting changes.
I say this year after year. The received wisdom of tracking the HEAD of the master branch is just not realistic for most businesses. Wonder needs proper release engineering.
Have a clear standard (stable version) for project Wonder (make sure the best option for each artefact is clearly identified).
Evangelism: Use a more widely seen video service for screencasts/podcasts so that a broader group of developers can find them more easily. (A Vimeo channel for example)
We need case studies on wocommunity.org. Something like http://www.apple.com/business/profiles/ should be good, a one-page where people explain how WO is good for their business and how they use it.
I think that one of the big drawbacks in the documentation right now is that there are too many references to historical configurations. It would be helpful to collate step by step documentation for the current stable versions of WebObjects, WOLips, MacOS X and release it as a community-sanctioned pdf.
For example at a minimum it would be helpful to have:
1. "Community Recommended Installation on MacOS X 10.6"
2. "Community Recommended Development Practices (running through Apache, bundle-less builds)"
3. "Community Recommended Deployment Practices"
New people don't need to know the history. They just need to know how they install WebObjects, Wonder, the tools, a database and get going for the current versions. This document set needs to be frozen and rereleased each time a major version change happens (whether Eclipse / WOLips, WebObjects, Wonder (affecting normal workflow) or MacOS X). That way we'll have documents archived for previous versions for those that need them, and straightforward current versions for everyone else coming to the platform.
Making Wonder independent from WebObjects is an excellent idea. Maybe it would enable a complete rewrite (one day).
We need to determine what is the best and "supported" way of installing WO and Eclipse/WOLips. Should we use WOInstaller.jar or the .pkg from Apple? Should we use Golipse for installing Eclipse and WOLips? When we figure out the best way, we have to update the wiki and wocommunity.org.
I 100% agree. There should be an official community supported method for installing eclipse / wolips / webobjects / wonder. All other flavours of installing stuff should be removed from the wiki.
As we also want to appeal to existing (Java-)programmers that already have their Eclipse environment set up it would probably make sense to have installation instructions / installers that only install the WO*bits into existing Eclipse.
We need a long tutorial about Wonder and WebObjects. That tutorial should present how to do a "regular" WO app, a D2W app and REST services built on top of the same model.
I'd be happy to work on that one, provided some people can give me some advice on the stuff I do not understand, and comment. I started with a tutorial about two years ago but stalled because the second chapter should be about DirectToWeb, and I hoped that somehow I could work around RuleModeler until later in the tutorial, but a fixed D2W Applet never materialized. Just let me know if some people are willing to help.
Ken Ishmimoto: We will record at the Bootcamp many Screen casts in Japanese for open releasing.
Assemble information regarding scalability of WO apps i.e. what software/hardware measures can be used with pros/cons, scalability commandments (like the EOF commandments), code examples to help newbies for concurrency issues, ...
I would like to see (and contribute to) a "cookbook" for WO programming tasks. There are existing examples (Ajax Example App) and I think cookbook organization (like the O'Reilly Cookbooks) would help those to be found and highlight needed recipes.
This is something I have been missing myself. I have put such cookbook code snippets into a text file that I regularly consult (yes, even after 9 years). Things like "How do I sort things" or "How do I filter objects", "How do I upload a file" are 1/2/3/4-liners in my reference. These things are trivial once you know them but for the beginner...?
I would gladly like to help here and hand over my snippets.
We need a way to link the JavaDoc and the wiki together. It could be special tags in the JavaDoc so that those tags are found, we automatically create a page in the wiki with a link to the JavaDoc.
Would be nice to have a way for Localization Javadoc in Wonder. To Help people make Documentation in other Language too. For my Part about 40% Documentation in japanese is done, but no way to write or share.
Perhaps this could be achieved with html. <p xml:lang="jp">Japanese Docs</p><p xml:lang="en">English Docs</p> Then it's just a stylesheet switch when the language changes.
Japanese stylesheet like
For the outputting JavaDoc that is a Solution, but I think there are 2 ways to lookup JavaDoc.
1. JavaDoc itself
2. In Eclipse hover over a Command