etf
|
Posted: October 11, 2010 11:47 by etf
|
| From this point we will go in two directions. First - 1.9.1 - maintenance release (with bugfixes and some backports); second - 2.0 - global redesign and many new features. Thus it is a prime time to start vote for new features. |
BSAF 1.9 have been released, so what is next?
16 posts
Replies: 15 - Last Post: July 03, 2011 17:37
by: vvUnai
by: vvUnai
showing 1 - 16 of 16
jekkos
|
Posted: October 16, 2010 13:08 by jekkos
|
|
I voted for BSAF-57. I think it should not be too hard to fix that. I once had a look at it myself and maybe if i find some more time I can propose a patch for this. I also voted for BSAF-92 as it is something I use quite often, FInally I voted for the TaskService isuses, I saw that BSAF-62 is a duplicate of BSAF-103 and I think the last one can be already included (as discussed before). and then there is BSAF-62 for creating TaskServices using the framework. grtz |
|
aloleary
|
Posted: November 27, 2010 18:28 by aloleary
|
|
Came across this article - May be interesting for future BSAF consideration. I know others have talked about Google Guice etc.. but as CDI is based on a now standard API this could be worth delving into in some more detail: http://blog.frankel.ch/lessons-learned-from-cdi-in-swing |
|
etf
|
Posted: January 13, 2011 09:54 by etf
|
|
from user jede: The biggest problem are the missing interfaces for nearly all (B)SAF components (especially for the ApplicationContext) and the "static" startup and creation of the framework. One of the major advantages of DI/IOC is the possibility to exchange central components of the application or the used frameworks. This makes custom implementations (e.g. of the ResourceManager) and unit testing much, much easier. Example: When I want to unit test my BSAF-based GUI components I need to wrap the ApplicationContext with an own class with similar functionalities. This wrapper uses an interface, so I can insert a mock of this context wrapper to the class to be tested. That's a lot of stupid code which would not be necessary... It would also be better when the BSAF components itself would use the idioms of DI. I don't mean to use a DI container, this would be oversized (and the application developer mostly wants to choose the container by himself). I mean that the BSAF classes must not instantiate the needed components itself across the whole framework. It would be much better, when every class will get all required dependencies passed. There should only be one class where all BSAF components are created and all dependencies are passed where necessary (similar to the Modules in Guice). And this class should be customizable. What do you think? Bye, Stefan |
|
etf
|
Posted: January 13, 2011 10:08 by etf
|
|
How I see the current state of BSAF? First of all I think I successfully complete the initial mission: BSAF is SAF compatible and stable framework. This work was targeted to the projects which already use Swing Application Framework. So, what is next? Original Swing Application Framework and BSAF is just a prototype which was rapidly integrated into Netbeans IDE for easier adoption. In respect of architecture it absolutely doesn't meet requirements of a mature framework. I have several big questions in mind: What feature does Swing have? Do we really need an application framework for java and swing? From the activity on this project I can see only from 10 to 20 applications/developers interested in BSAF. It is not a big audience at all. Please take into account that there are several new and all application platforms for java already. Do we need one more? Why I asking that? Because what was described in previous post (and I fully support those ideas) is a brand new framework. The best thing we can do concerning BSAF users is provide a clear migration plan, because the new framework will be not compatible with the old one. |
|
jede
|
Posted: January 13, 2011 10:22 by jede
|
|
These are good questions. I think BSAF will never get such a big user group as there are for the big RCP platforms. But I think that there is still a demand for small or medium sized Swing applications which doesn't want the full RCP stack and all the disadvantages coming with RCP (startup time, download size, memory consumption, complexity, ...). I also don't think BSAF / SAF has missing features, it's almost all there. But the framework design could get some improvements (as you can see in my post above). |
|
jede
|
Posted: January 14, 2011 19:43 by jede
|
Not really. The interface based API's with will be mostly the same, but the methods (or constructors) for the "creation process" will differ. So it's a topic for BSAF 2.0  The downside of interface API's is, that the interfaces are harder to change in the future. So their content must be carefully checked before declaring the API as final... |
showing 1 - 16 of 16
Replies: 15 - Last Post: July 03, 2011 17:37
by: vvUnai
by: vvUnai
