Eric Heumann
|
Posted: April 05, 2010 20:06 by Eric Heumann
|
|
Would anyone like to report on the current status of the Resource improvements/enhancements? What it looks like... It seems like back in October or so, Rob Ross presented several significant improvement options for the resource features in BSAF. There's a page in the wiki discussing them, and a JIRA issue, BSAF-35, was created. It seems like a branch in the code repository titled 2.0 was created to implement this. The last change in that branch was back in December though, and I haven't seen a post from Rob Ross since January. There were some issues about IntelliJ artifacts in that branch, and those were supposedly cleaned up, but when I look at that code in that branch there's still a JetBrains folder and a lot of @NotNull business going on. It also looks like there still may be some work to do to implement all those features. More recently, a JIRA issue, BSAF-72, was logged asking if one of the new features, name and type caching, should be included in the 1.9 code. No one's really said much about that, and it doesn't look like much has been done about it. So... Has work on the 2.0 branch been abandoned? How serious are people about implementing the enhancements Rob Ross mentioned, and perhaps more? Are there issues with them? Do they need more thought? Or do we just need some more manpower to make it happen? Personally... I liked a lot of what Rob had thought up. It got me looking through the code and thinking about the design. I know this project (BSAF) has a core mission of just gutting bugs and doing simple fixes to SAF, but I think the resource improvements that have been mentioned would be appreciated by many folks, and I think it would be pretty easy to maintain compatibility with SAF 1.3. It was nice to see Jim Mochel offer to help with the documentation. If you'd like my help with these resource features (or any of the other issues I've been involved in), I'd be happy to become a member of the project as well. Just let me know what I can do. Thanks, Eric |
What's the status on Resource improvements?
7 posts
Replies: 6 - Last Post: August 10, 2010 06:01
by: robross
by: robross
showing 1 - 7 of 7
etf
|
Posted: April 07, 2010 05:16 by etf
|
|
Thank you, Eric, for your post! The main problem of the project is lack of "manpower" at the moment . The changes introduced in 2.0 branch is really awesome but they need a careful review. Current primary targets for BSAF are fixing bugs and improve documentation. You know, it is always a fun to implement new exiting feature, but this library as a product should be robust and stable and well documented in the first place. |
|
Eric Heumann
|
Posted: April 08, 2010 02:17 by Eric Heumann
|
|
OK cool, thanks! What can we do to expand documentation and examples? Are we going in the direction of creating Wiki pages on this site? Or are we thinking of developing a website front for the project? Also, do you have an idea of which classes need the most javadoc work? I'd like to get your (and/or others') opinion and recommendation before I just set off working on something. Thanks, - Eric |
|
etf
|
Posted: April 08, 2010 06:04 by etf
|
|
I'm just explaining my vision. JavaDoc The most important part. We have no explicit demarcation between framework API and implementation. Hence JavaDoc should be supplied/updated for all classes. I see two reasons here: 1. help developers use the framework 2. help developers understand and contribute into framework Wiki We could put small articles on the wiki. Something like FAQ, HOW-Tos, etc. BSAF Reference Documentation IMHO should be developed as a independent entity. I'm thinking about docbook format. |
robross
|
Posted: August 10, 2010 01:26 by robross
|
|
The NotNull and Nullable annotations are a way to communicate clearly when a method argument allows null values, and document to the caller if the return value may be null, thus require a null check. These have long been proposed as additions to the standard annotations the compiler understands. My particular IDE, IntelliJ IDEA, has implemented them both as documentation annotations, and actual compile-time modifications of the methods. These annotations cause byte code to be inserted that checks these conditions and throws exceptions if the constraints are violated. However, it was determined that this external dependency should not be introduced into the framework. So I am using the annotation source code definitions from IDEA, which are just Java @interface source code, and are allowed to be distributed as such. I'm only using them as documentation annotations, and everyplace in the code where they're used, I'm including an explicit check on the arguments. So there's no dependency, it's straight Java code, and I can still document these important intentions. Caching in the 2.0 branch is implemented on a per resource, per type basis. --------------------------------------------------------------------------------------------------- I've always been unhappy at having to remain compatible with the original SAF. I understand why this is useful, but the SAF was about testing out these ideas and to come up with something really good, yet as soon as they included it in NetBeans the API became public and "sticky." I've been working on my own App framework that is loosely based on the concepts of SAF, but that will not be compatible. I'm focusing on Actions as the primary way to specify, well, Actions - like SAF. But I'm basically making them all proxies, in which the actual Action command method can be dynamically swapped out in different contexts. And I'm working on implementing about 300 standard Actions that are present in most applications, things like New, Open, Save, SaveAs, Print, Cut, Copy, Paste, RecentItems, etc. And I'm building in Internationalization from the start, so all of these standard commands will be localized in as many languages as possible, and eventually with community support, all languages that anyone using Java would need. I've implemented a Menu template definition language so building application menus is as simple as defining something like: define menubar:default menu:fileMenu //defined in DocumentApplication.menus menu:editMenu //defined in DocumentApplication.menus menu:windowMenu //defined in DocumentApplication.menus menu:helpMenu //defined in DocumentApplication.menus endmenubar Where all the standard menus and their command implementations are part of the framework. Anyway, that's mainly why I have not been active in this project, I've been working on my own  Rob |
|
robross
|
Posted: August 10, 2010 06:01 by robross
|
|
I'll be happy to when I have it in a relatively stable form. My goal is to first implement 3 non-trivial applications in order to evolve the framework to support them. I'm finishing up on a NotePad type app right now. I will also work on a simple Paint type application, then some sort of "single frame" application. I chose to start with a document framework since that was one of the glaring omissions of the SAF. I think a "Single Frame" type app is a special case of a document framework, so that part should not be too hard. But I still have a fair bit of work to do before I can publish anything. Are you able to attend JavaOne this year? If so I'd be happy to demo what I have so far. Rob |
showing 1 - 7 of 7
Replies: 6 - Last Post: August 10, 2010 06:01
by: robross
by: robross
