One difference would be that it would be statically typed language.
It would recognize entities as classes (not java classes, but it would use
internally
map as it is now). That is difference compaing to current java or mini
language where entities names and properties are strings. The language it
self
would be generic PL/SQL similar language with support for many query
languages
SQL/EJB3/???.
Second difference would be way of defining objects (entities, forms, menus,
roles,code, translations).
There would altering language for it. The whole object repostiory would be
created
from some kind of langugage. That would give power to customizations
becouse
all definitions and code could be altered. In fact it would be some kind of
object database
but which could be alterable. The power of altering is great.
Third object repository would be faster than parsing tons of xml files. it
could be dbms like in
case of Compiere/Adempiere/OpenERP (the best becouse the whole language
could be applied to both metaobjects
and entities) or serialized object. Current Compiere
user experience is not good becouse compiere does not use
repository/dictionary cache, but this is mainly
due to not well designed transaltion tables which can not be easly cached
without context.
And the most important thing. From my experience there is currenty huge
problem
with business applications. Even if there is reusable business logic on the
server side
it can not be generic purpose.
Business logic can be:
-line centric where all entities inserted and treated just as table
lines
-gui centric where business logic is correspond to user interface
-document centric where entities are treated as documents
First one is easy to create but not friendly to developer.
Second one is easy but not very reusable or scalable e.g. batch mode when we
want
for exmaple import entities.
third one is optimal but unfortunetely currently not well supported becouse:
-it must reimplement the gui logic (e.g default values)
-The all checks from gui must be reimplemented. All rules must be
applied in case we do not trust our client
-It is difficult to find changes compared to saved version in case of
update.
So the best way would be to create framework which would operate on
changelog of entity. In some scenarios the changelog would be created by gui
in some scenarios changelog would be created based on database state of
entity.
Then we would apply set of rules/triggers on this changelog. The rule
can be applied for example to remove of order item.
The rules could be reusable on gui and server side. GUI would send us
direct changelog made by user and we would reapply it on server.
In case of batch mode we would create changelog comparing new state
to db state and also apply rules.
Rules would opearte on documents so there would be no uncessery
database traffic.
The whole language would be change log based. Eg.
replace|create|drop|update form [id] as
add panel name as
[replace] row name before anotherPanel as
renderer OrderDate;
renderer OrderStatus;
end
end
end
create entity Invoice as
property InvoiceDate date;
property Description string;
service Complete as
param force boolean optional true default false;
param ignoreWarning optional true default true;
code as
code goes here.
end
end
end
update Invoice 435245 as
update Party 'CUST1000' //this would resolve party by id
calculated MechCont 'CUST1000_1' //calculated keyword would indicate
that it is not updated from gui.
update lines as
replace line 10 //seqeunce id
product 'GIMZO'; //this would resolve product by id
quantity 10;
end
add line
product
name 'Best Gimzo'
end //this would resolve product by 'query by example'
quantity 10;
end
end
calculated taxes as
end
end
The whole language would XML like but more readable with following rules
Optional ?? create/replace/drop/update/calculated keyword to indicate
operation on object.
As keyword to indicate block start.
Before/After keywords to indicate position.
end keyword to indicate block end.
; to indicate one line end;
object type after create/replace/drop/update keyword to indicate what to
change.
It would also determine inline options for line [id of object and other
options;
In fact what is new compared e.g. to Groovy builders is that it is alter
aware language.
It would be nice both in metaobjects updating as in entities updating.
Cheers,
Marek
----- Original Message -----
From: "BJ Freeman" <[email protected]>
To: <[email protected]>
Sent: Sunday, May 24, 2009 1:28 AM
Subject: Re: OfBiz 4GL
and how ofbiz mini lanquage not support this?
seems your stating what ofbiz does.
How about some concrete examples, comparing ofbiz minilanguage to what
you propose.
Marek Mosiewicz sent the following on 5/23/2009 8:32 AM:
AspectJ gives chance to override business logic. That is true. But what
I would see is some kind of object database with stored proedure
language.
That would be ultimate solution for many places where lot of
customizations is needed. You could override any thing you need. Either
column,
form field or business logic.
In fact what is closest to my mind is the SQL99 where there is standard
language and quite nice object features. But unfortunetly it is still
not implemented except DB2.
Marek
----- Original Message ----- From: "Ján Valkovič" <[email protected]>
To: <[email protected]>
Sent: Friday, May 22, 2009 11:03 AM
Subject: Re: OfBiz 4GL
Hi,
My 5 cents. What about AspectJ http://www.eclipse.org/aspectj/ as
implementation of "your" language?
ya
Dňa Št, 2009-05-21 o 20:58 +0200, Marek Mosiewicz napísal:
Compiere does not do this in elastic way. There is no way to alter
service
definition as it is normal java method. There is no language to make
change.
All changes must be done in database via GUI.
I do not thing there is problem with UI changes. The UI could be
altered in
same way as entity (there is just important sequence of fields so some
positioning keywords should be available).
I know that there is alredy infrastructure in OfBiz to do this. That
it is
why I write here.
Best regards,
Marek
----- Original Message ----- From: "BJ Freeman" <[email protected]>
To: <[email protected]>
Sent: Friday, May 15, 2009 6:26 PM
Subject: Re: OfBiz 4GL
> There are applications like Compiere that use this. so Why change >
ofbiz?
> Also how about addressing some of the inherited features like UI and
> DB(at least the adds) change when entities changes
> Then there is the automatic Creation of CRUD services that get built
> from the Entity.
> Triggers are covered under ECA's
> Also the ECA's let you model your business flow the way a clients >
needs.
> For those that need java the services can be written in Java with
just > a
> simple service interface.
>
>
>
>
> Marek Mosiewicz sent the following on 5/15/2009 3:24 AM:
>> What could be very interesting would be to add new language to
OfBiz. >> It
>> could be some 4GL which would
>> bring many interesting features:
>>
>> First it could be service writing languge. It could be static
language
>> which would make it types based on entities
>> and services (maybe services could be more entity coupled) and
could >> be
>> more user freindly than XML mini language.
>>
>> Second it could be system repository manipulation language.
>> Currently
>> Ofbiz has XML repository of entities services
>> and forms. But imagine that we store it in database or just as
>> serialized java object. Now add to this manipulation language like
>> this:
>> ALTER CLASS Invoice
>> ADD PROPERTY AdditionalDescriptions
>> BEFORE:Description
>> TYPE: Text
>> LENGTH: 400
>> END
>> REPLACE SETTER TRIGGER MyTrigger
>> PHASE:BEFORE
>> LANGUAGE: OFBIZ
>> TARGET: AdditionalDescriptions
>> CODE
>> TaxId = Nip
>> END
>> END
>> ADD SERVICE TRIGGER CompleteAdditional
>> TARGET : Complete
>> PHASE: AFTER
>> LANGUAGE: JAVA
>> CLASS :org.apache.ofbiz.addins.InvoiceJMSNotification
>> END
>> END;
>> ALTER CLASS Order
>> ALTER ACCESS RIGTH Access
>> ALTER ROLE Marek
>> READ: TRUE
>> WRITE TRUE
>> DELETE: FLASE
>> END
>> END
>> END
>> ALTER FORM Invoice
>> ALTER GROUP Main
>> ADD RENDERER AdditonalDescription
>> END
>> END
>> END
>> ADD TRANSLATION
>> LANGUAGE:pl_PL
>> KEY: Invoice.AdditionalDescriptions
>> END
>> Some parts of language could be client available like validation
rules
>> for example.
>> It would be something like dynamic application server. You could
alter
>> the main code whch would make platform very good
>> for components.Anyone could easly alter componetns for its needs.
>> Another great thing would be use of Ofbiz with some ORM, the best
>> would
>> be OpenJPA but it currently works only on
>> class level (no support for Map entites).
>>
>> Best regards,
>> Marek
>>
>
> -- > BJ Freeman
> http://www.businessesnetwork.com/automation
> http://bjfreeman.elance.com
>
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
> Systems Integrator.
>
>
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
