Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 11 total
Thread Excelent work + really needed features
Tue, Feb 17 2015 5:35 PMPermanent Link

Wilhelm Kipper

 First I have to say excelent work. I dind't try it the product yet but
I read the documentation and some of the newsgroups messages and playing
with ready-made online demos.

Having a responsive JS frontend written in Object Pascal is brilliant,
especially that json request can be completed from a variety of sources.
The first example in my mind is KbmMW 3-tier framework, where the same
server exe can serve Delphi native clients and json/web clients (just
activating one more service (HTTPSERVICE)).

Now, some needed features and advices for really responsive app:
1. OnFilterRecord for TDataset. Parser is little hard to implement, but
OnFilterRecord should be easy.
2. LookupComboBox(with multiple columns) with incremental search
filtering. In the grid also.

When coding my desktop clients, first I fully load all my lookup tables
on memory tables(because usually are not so big and not change so
often). From time to time, when for example when I load OrderForm, first
I check there are changes in Customers and Products table and then I
download only changes and apply them to those memory tables. This give
to me a very responsive app. I think the same can be done with EWB. So:

3. (Related to 2) Any chance that TDataset will have column type
dtLookup? So will not be necesary to join tables on server and I can use
the local-client already loaded memory tables(lookup tables).
4. Will be possible when I make the json call to webserver to bring in
one server call multiple datasets changes and apply to them - something
like TDatabase.Load([array of datasets])? (Must be easy since you're
making this when you are comiting a transaction). This is very useful
(and speedy)  to bring updates to lookup datasets in one server call.

Devexpress had so success because they understood that final users love
rich grids with sorting, filtering, grouping. So, some suggestion:

5. Make a top priority to enhance the grid control: a) Search Panel - in
top part of the grid an optionally nice panel with a text box which can
make incremental search filtering on all columns with eventually text
highlighting. (the same code can be used to make the control from 2.);
b) Autofilter; c) grouping - when you have time.

So after all you'll need a virtual TDataset. And one more: kbmMemTable
has a very nice AttachedTo option - any memory table can be attached to
another (master), it uses the internal records of the master but every
memory table has it's own sorting, filtering, it's own edit state. When
changes appear, they have an internal Lock mechanism to updates the
internal records of the master. This is enormous useful: the
master-dataset can be a source for lookup field, and client-dataset can
have a filter applied for searching in another form, etc. This is very
useful in threads also if you think about implementing multithreading.
Wed, Feb 18 2015 4:02 AMPermanent Link

Matthew Jones

Wilhelm Kipper wrote:

> Now, some needed features and advices for really responsive app:

That's a good list of requirements. The new EWB 2 (in preview, see the
preview group), will answer some of them, but mainly by enabling us to
develop and share components more easily. The back-end data access is
certainly something you can do, but while EWB has a really nice
database link, where you can get the results of queries, you may need
to do more yourself for the updates you suggest, etc.

I've posted about how you have basically two alternatives with EWB
applications and data access, either using the "native" database links,
which are fine for many purposes, or accessing a back end API via REST
or another system (I use RemObjects SDK) which can then provide the
data you need. Because the browser is asynchronous, you can do a really
quite good job with fetching data in the background. And the object
oriented code allows you to build up objects to store that data for
cache purposes.

Fundamentally, EWB is very flexible, and the new version will allow a
smart grid to be developed. It's a tool worth investing in IMO.

--

Matthew Jones
Wed, Feb 18 2015 6:37 AMPermanent Link

Wilhelm Kipper


> That's a good list of requirements. The new EWB 2 (in preview, see the
> preview group), will answer some of them, but mainly by enabling us to
> develop and share components more easily. The back-end data access is
> certainly something you can do, but while EWB has a really nice
> database link, where you can get the results of queries, you may need
> to do more yourself for the updates you suggest, etc.

Yes, database link is very nice and I think I can always can make
TDataset descendant that has a method
TDatasetDescendant.LoadFromDataset(dsAnotherWithOnlyUpdates) based on
KeyFields of the dataset, but to bring together in one server call
multiple datasets I think must be done by Tim

Regarding creating components: I watched the video about creating a new
component. Really impressive and giving the possibility of 3rd party to
create full components means the true life of EWB from now on is just
STARTING. But attention, here must be some big thinking:
1. When EWB2 is just mature enough, Object Pascal must be easy
interchangable with C#. Think about hundreds of thousands of C# Winforms
developers who must make web but hate JS. They can do .NET on server
side and EWB on webclient-side. Here advertising and more support is needed.
2. Some packaging/protection of components. Vendors like TMS will invest
in making components for a growing system like EWB OP/C# but with the
assurance that they can monetize the investment and not everyone has
access to their components copying just one unit file. Think about
PivotGrid, VerticalGrid, Scheduler,...

> I've posted about how you have basically two alternatives with EWB
> applications and data access, either using the "native" database links,
> which are fine for many purposes, or accessing a back end API via REST
> or another system (I use RemObjects SDK) which can then provide the
> data you need. Because the browser is asynchronous, you can do a really
> quite good job with fetching data in the background. And the object
> oriented code allows you to build up objects to store that data for
> cache purposes.

I understand that, KbmMW is exactly what Remobjects do. That's the all
idea - to connect to existing middle tier, use the existing code, and
improve web performance but using some caching mechanism on client side.

> Fundamentally, EWB is very flexible, and the new version will allow a
> smart grid to be developed. It's a tool worth investing in IMO.

I agree, in EWB2 it's a 100% worth investing. So I'm waiting for EWB2
launch Wink
Wed, Feb 18 2015 7:12 AMPermanent Link

Matthew Jones

Wilhelm Kipper wrote:

> Yes, database link is very nice and I think I can always can make
> TDataset descendant that has a method
> TDatasetDescendant.LoadFromDataset(dsAnotherWithOnlyUpdates) based on
> KeyFields of the dataset, but to bring together in one server call
> multiple datasets I think must be done by Tim

It's just code, so it could be done by anyone. I've fixed things in the
past, then given Tim the code to review so that he can either
incorporate or do it his way.



> 1. When EWB2 is just mature enough, Object Pascal must be easy
> interchangable with C#.

It's an idea - but probably some more market success has to come first.



> 2. Some packaging/protection of components.
> Vendors like TMS will invest in making components for a growing
> system like EWB OP/C# but with the assurance that they can monetize
> the investment and not everyone has access to their components
> copying just one unit file. Think about PivotGrid, VerticalGrid,
> Scheduler,...

I'm not sure how this could ever be done in a practical way. My first
thought was that the files could be provided in an encrypted way, but
how does the key get to me, the user, for the IDE to use? If I have the
files and the key, I can just give them to the world anyway. Only if
ElevateSoftware use public-private keys, and do the encrypting for the
developers, would it be possible (the IDE having the public key for
reading), but then if the key is in the IDE I can hack it anyway (well,
someone could). I suspect that a simple "keep honest people honest"
system would be the best option. Just like Delphi components.


> I understand that, KbmMW is exactly what Remobjects do. That's the
> all idea - to connect to existing middle tier, use the existing code,
> and improve web performance but using some caching mechanism on
> client side.

FWIW, I don't use their data layer, just the SDK which is the remote
procedure calls. Sort of like REST but not. I never really liked the
idea of using an intermediate database layer, perhaps having been
bitten by Asta.



--

Matthew Jones
Thu, Feb 19 2015 11:23 AMPermanent Link

Wilhelm Kipper

>> 2. Some packaging/protection of components.
>> Vendors like TMS will invest in making components for a growing
>> system like EWB OP/C# but with the assurance that they can monetize
>> the investment and not everyone has access to their components
>> copying just one unit file. Think about PivotGrid, VerticalGrid,
>> Scheduler,...
>
> I'm not sure how this could ever be done in a practical way. My first
> thought was that the files could be provided in an encrypted way, but
> how does the key get to me, the user, for the IDE to use? If I have the
> files and the key, I can just give them to the world anyway. Only if
> ElevateSoftware use public-private keys, and do the encrypting for the
> developers, would it be possible (the IDE having the public key for
> reading), but then if the key is in the IDE I can hack it anyway (well,
> someone could). I suspect that a simple "keep honest people honest"
> system would be the best option. Just like Delphi components.

Yes, but Delphi has .dcu and .bpl so trials can be made.
Thu, Feb 19 2015 1:30 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 2/19/2015 11:23 AM, Wilhelm Kipper wrote:
> Yes, but Delphi has .dcu and .bpl so trials can be made.

Yes but those are binary as is the delphi executable exe.

EWB is all javascript throughout so even the final app "source code" is
accessible in the end-user browser.

One can obfuscate the code but that just adds some annoyances and does
not protect anything really (and makes it tough to debug on end-user
system).

Raul
Fri, Feb 20 2015 11:38 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Wilhelm,

<< First I have to say excelent work. >>

Thank you. Smile

<< Now, some needed features and advices for really responsive app: 1.
OnFilterRecord for TDataset. Parser is little hard to implement, but
OnFilterRecord should be easy. >>

This has been requested a lot, so it will probably be addressed in the first
"cleanup" round of improvements for EWB 2.  At this point, it doesn't look
like something that I'll do for the *initial* release, but I may have time
to deal with it when I'm in there modifying some aspects of the transaction
commits.

<< 3. (Related to 2) Any chance that TDataset will have column type
dtLookup? So will not be necesary to join tables on server and I can use the
local-client already loaded memory tables(lookup tables). >>

You don't absolutely need such a thing right now - you can use the
OnRowChanged event to load detail datasets dynamically based upon a master
row.  This is what the master-detail example project shows.

<< 4. Will be possible when I make the json call to webserver to bring in
one server call multiple datasets changes and apply to them - something like
TDatabase.Load([array of datasets])? (Must be easy since you're making this
when you are comiting a transaction). This is very useful (and speedy) to
bring updates to lookup datasets in one server call. >>

Sure, that's certainly possible.

<< 5. Make a top priority to enhance the grid control: a) Search Panel - in
top part of the grid an optionally nice panel with a text box which can make
incremental search filtering on all columns with eventually text
highlighting. (the same code can be used to make the control from 2.); b)
Autofilter; c) grouping - when you have time. >>

This is always just a matter of resources.  I have to try and deal with
foundational aspects of the product before I can deal with more advanced
functionality in the controls.  This is where I hope 3rd party vendors can
step in with EWB 2, to some degree.  I spent a *lot* of time this last year
making sure that control development was as easy as possible in order to
facilitate easier acceptance for 3rd party vendors.

<< And one more: kbmMemTable has a very nice AttachedTo option - any memory
table can be attached to another (master), it uses the internal records of
the master but every  memory table has it's own sorting, filtering, it's own
edit state. When changes appear, they have an internal Lock mechanism to
updates the internal records of the master. This is enormous useful: the
master-dataset can be a source for lookup field, and client-dataset can have
a filter applied for searching in another form, etc. This is very useful in
threads also if you think about implementing multithreading. >>

Some of what you're describing would not be possible due to the lack of the
appropriate browser primitives to handle such functionality, but the
attached dataset concept would probably be useful.

Tim Young
Elevate Software
www.elevatesoft.com
Fri, Feb 20 2015 11:51 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Wilhelm,

<< 1. When EWB2 is just mature enough, Object Pascal must be easy
interchangable with C#. Think about hundreds of thousands of C# Winforms
developers who must make web but hate JS. They can do .NET on server side
and EWB on webclient-side. Here advertising and more support is needed. >>

This is a questionable proposition.   We've tried to make inroads in the
C#/.NET world with previous products, but, to be honest, C# developers tend
to not be interested in anything that isn't provided by MS.  IOW, it would
be a hard sell competing against ASP.NET *regardless of the merits of our
product*.   And I mean that with a *lot* of emphasis on the last part. Wink

I've certainly thought about the idea of multiple language support in the
IDE, but it would be a pretty big undertaking...

<< 2. Some packaging/protection of components. Vendors like TMS will invest
in making components for a growing system like EWB OP/C# but with the
assurance that they can monetize the investment and not everyone has access
to their components copying just one unit file. Think about PivotGrid,
VerticalGrid, Scheduler,... >>

I'll have to think about this some more.  It's certainly possible to do, and
would probably involve a password-protected binary format for extracting
installed components from a package.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com
Fri, Feb 20 2015 4:00 PMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

As a C# developer I can state that although it would be nice I really
don't mind the Pascal syntax as if I get stuck the support from the
newsgroup and Tim soon gets any problems sorted.

Chris Holland
[Team Elevate]

On 20/02/2015 16:51, Tim Young [Elevate Software] wrote:
> Wilhelm,
>
> << 1. When EWB2 is just mature enough, Object Pascal must be easy
> interchangable with C#. Think about hundreds of thousands of C# Winforms
> developers who must make web but hate JS. They can do .NET on server
> side and EWB on webclient-side. Here advertising and more support is
> needed. >>
>
> This is a questionable proposition.   We've tried to make inroads in the
> C#/.NET world with previous products, but, to be honest, C# developers
> tend to not be interested in anything that isn't provided by MS.  IOW,
> it would be a hard sell competing against ASP.NET *regardless of the
> merits of our product*.   And I mean that with a *lot* of emphasis on
> the last part. Wink
>
> I've certainly thought about the idea of multiple language support in
> the IDE, but it would be a pretty big undertaking...
>
> << 2. Some packaging/protection of components. Vendors like TMS will
> invest in making components for a growing system like EWB OP/C# but with
> the assurance that they can monetize the investment and not everyone has
> access to their components copying just one unit file. Think about
> PivotGrid, VerticalGrid, Scheduler,... >>
>
> I'll have to think about this some more.  It's certainly possible to do,
> and would probably involve a password-protected binary format for
> extracting installed components from a package.
>
> Thanks,
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
Sat, Feb 21 2015 8:31 AMPermanent Link

Wilhelm Kipper

> << 3. (Related to 2) Any chance that TDataset will have column type
> dtLookup? So will not be necesary to join tables on server and I can use
> the local-client already loaded memory tables(lookup tables). >>
>
> You don't absolutely need such a thing right now - you can use the
> OnRowChanged event to load detail datasets dynamically based upon a
> master row.  This is what the master-detail example project shows.

I was talking lookup fields like in Delphi. Ex:
Dataset dsORDERS: ID, ID_CUSTOMERS, AMOUNT;
Dataset dsCUSTOMERS: ID, NAME, ADRESS;
ID_CUSTOMERS is lookup field - contains a integer value pointed to ID
from dsCustomers, but when ID_CUSTOMERS is connected to dbaware control
displays NAME.
Otherwise, I have to make a SQL join between those 2 tables, so when I
fetch ORDERS dataset I'll have the following columns: ID, ID_CUSTOMERS,
NAME_CUSTOMERS, ADRESS_CUSTOMERS, AMOUNT.
I hope I made myself understood.


> << 4. Will be possible when I make the json call to webserver to bring
> in one server call multiple datasets changes and apply to them -
> something like TDatabase.Load([array of datasets])? (Must be easy since
> you're making this when you are comiting a transaction). This is very
> useful (and speedy) to bring updates to lookup datasets in one server
> call. >>
>
> Sure, that's certainly possible.

It's possible now? or in a future release?


> << And one more: kbmMemTable has a very nice AttachedTo option - any
> memory table can be attached to another (master), it uses the internal
> records of the master but every  memory table has it's own sorting,
> filtering, it's own edit state. When changes appear, they have an
> internal Lock mechanism to updates the internal records of the master.
> This is enormous useful: the master-dataset can be a source for lookup
> field, and client-dataset can have a filter applied for searching in
> another form, etc. This is very useful in threads also if you think
> about implementing multithreading. >>

It's extremely important that a programmer has the tools to make apps
with separation logic from GUI. Otherwise maintenance is a real pain.
That's why Delphi has DataSource, DataModule. ClientDataSet and
kbmMemTable they have AttachedTo with the same purpose.
Let me explain a little bit about my Delphi Win 32 process regarding
separation of concerns and please tell me this scenario can be applied
to EWB:

For every form I have:
1. FormUnit (only GUI and simple interaction, dbaware/grid controls and
DataSource pointed to 2.);
2. BussinessLogicClassUnit (inherited from TDataModule, a class module
with properties/methods, contains kbmMemTable/ClientDataSet attached to
dataset in 3.) - OnCalFields, OnNewRecord, .. is here,
OnBeforePost/Validation is here;
3. DBConnectionUnit (one DataModule for whole app, always loaded with
dbconnection, transaction components and of course TDatasets descendants
connected to db tables/sql.

DBConnectionUnit doesn't know nothing about BussinessLogicClassUnit,
which doesn't know nothing about FormUnit. This setup works perfect and
is simple to maintain. It's possible with EWB this setup? I don't see
DataModule unit, DataSource component, Attached property.

Page 1 of 2Next Page
Jump to Page:  1 2
Image