GroundWork CSS

Being an excelent idea and and solution Buildap still have problem with popularity because it does not easy integrate into the development technologies particularily Java development. It is important to make it be easy usable from within the Java code.

Limitation of Buildap approach

The idea is great – imitate electronic circuit board development approach in software development, but does electronics fit into software world.

The nature of electronics is asynchronous while software has both synchronous and asynchronous behavior.

Buildap lacks in synchronous behavior, which is natural to software those it creates obstacle for using it in real day by day tasks.

Buildap value

The value of technology is in easiness of usage with other technologies particularly from within the Java code. For example simple “Add” part in Buildap which takes two parameters as input to inpin and fires result as outpin is still difficult to use from Java code, not saying about more complex parts.

Popular frameworks gain popularity not by providing beauty solutions but by providing value to the end user. Like Spring framework it is easy to use it from within Java code, it can integrate both way and does not impose itself to business Java code building everything via interfaces.

I advocate usage of Buildap from within Java code and vice versa those providing value to each other currently Java codes can be used in Buildap environment but Buildap usage from Java is not that easy.

Proposed usage scenarios can be:

public static void main(String[] args) {

int arg1 = 5;

int arg2 = 4;

int sum = 0;

Part part = BuildapContext.getPart(“Add”);

BuildapEvent be = new BuildapEvent();

be.addArg(arg1);

be.addArg(arg2);

part.addOutPinEventListener(new IOutPinEventListener(){

public void outPinFired(BuildapEvent be){

sum = be.getArgAsInt(0);

System.out.println(“sum=”+sum);

}

});

part.fireInpin(“add”, be);

}

NOTE: This is not real Buildap code, it is proposal but it is also not that convenient usage.

The problem here is that parts in Buildap does not have named instances and named scopes (or fully qualified names) which makes it difficult first to identify correct Add part because in the Buildap environment there can be several Add parts loaded, assuming that Add part can have a state it is not correct to look for a part by type.

Proposal: parts need to have instance names/ids and scopes. (as well as access rights desired feature)

Some inpin and outpins act in synch although there is no notation in Buildap for it. For example Add part has one inpin which takes two arguments and fires outpin whenever it receive arguments for inpin and outpin implicitly related to each other.

There remains other outpins which are not in synch with any inpin which remain event oriented.

Proposal: pins which are in synch with each other need a kind of notation to indicate behavior.

So the code above can be simplified to:

public static void main(String[] args) {

int arg1 = 5;

int arg2 = 4;

int sum = 0;

Part part = BuildapContext.getPart(“add1”);//named id of Add part

BuildapEvent be = new BuildapEvent();

be.addArg(arg1);

be.addArg(arg2);

BuildapEvent result = part.fireInOutpin(“add”, be);

sum = result.getArgAsInt(0);

System.out.println(“sum=”+sum);

}

Error pin event can be translated to the JavaException then firing part of code will change to

try {

BuildapEvent result = part.fireInOutpin(“add”, be);

sum = result.getArgAsInt(0);

System.out.println(“sum=”+sum);

} catch (BuildapException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

For adding value to Buildap there need to be full qualified paths because different independent parts can be used like two SoapClient parts; one in ticket reservation SoapClient stateful part with fully qualified path ticketreservation.soapClient1 and other ordermanagement.soapClient1

Proposal: It should be possible to work synchronous when pins are not physically in synch but event fired to a given pin will sooner or later definitely produce event from other pin.

public static void main(String[] args) {

int arg1 = 5;

int arg2 = 4;

int sum = 0;

Part part = BuildapContext.getPart(“add1”);//named id of Add part

BuildapEvent be = new BuildapEvent();

be.addArg(arg1);

be.addArg(arg2);

Part otherOrSamePart = BuildapContext.getPart(“xxx”);//named id of Add part

try {

/**

* this will make hang code in the fireSynchronized(..) method till the result from namedIdOfPin not provided

*/

BuildapEvent result = part.fireSynchronized(“add”, be, otherOrSamePart.getPin(“namedIdOfPin”));

sum = result.getArgAsInt(0);

System.out.println(“sum=”+sum);

} catch (BuildapException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

Part state:

A part is not only consuming events and produce events, part has can have state. Sure state can be modified via Buildap events or other type of events, but there is strong similarity of Buildap part with the Java bean and why not part also can have properties, which can be set explicitly.

Remarks:

There is strong similarity between Java bean and Buildap part the single and obvious difference is a way of communication Java beans use direct references to each other those ensuring object oriented approach of communication while part uses link (as first class citizen object) to communicate with other parts those ensuring anonymous collaboration between parts those ensuring component oriented approach.