Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 20 of 32 total
Thread Elevate Web Builder 2: Component Developers Preview Video
Tue, Nov 18 2014 5:10 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< Looking really nice. I can see the layout system is going to be very
powerful, but also give us a bit of conversation about how to achieve a
particular mode. My first thought is that it might be handy to have a mode
where you can have arrows or indicator lines or something to indicate the
"flow". But I love the margins that give the spacing, instead of the old
"stack of panels" that was once the way. >>

Because all of the designers are now custom-drawn, I can pretty much do
anything that we want with the look and feel.  The selection handles,
rectangles, indicators, etc. can all be customized, and I'll be certainly
taking suggestions on how to make them work as effectively as possible.

<< It also appears that the components are "pure pascal" and not Javascript
at all. Which is fine of course - there is a lot of power there. It would be
nice to be able to incorporate standard Javascript components, but with 1.x
I've done full native "components" and they have worked well. >>

The issues with using JS components is the same as with EWB 1.x - the JS
components simply don't have any idea that they're running in an EWB
environment, so they don't notify EWB when their dimensions, etc. change.
EWB requires that it be notified of such changes so that it can update
information that it caches about the various UI elements.  EWB 2 is even
more sensitive to this, because it is literally a layer unto itself that
sits on top of the browser's DOM.  It *has* to be this way, otherwise an
interactive design-time environment is not possible.  Having said that, with
EWB 2 as long as you wrap the JS component at the UI layer, then you can at
least layout the component at design-time.  There's a special way to wrap
underlying DOM elements so that they are usable in the normal EWB control
hierarchy (this is not required, but it makes the elements easier to use
with controls at higher levels).

But, in general, you shouldn't need JS components as much with EWB 2, and
I'll take a second to try and explain why.  The TGroupPanel that you saw in
the video ?  It took all of about 10 minutes to create, and here's how
simple the class declarations are:

  TGroupPanelControl = class(TControl)
     private
        FCaptionElement: TElement;
        FClientElement: TElement;
        FClientTopMargin: Integer;
        function GetBackground: TBackground;
        function GetCaption: String;
        procedure SetCaption(const Value: String);
        function GetFont: TFont;
        function GetInsetShadow: TInsetShadow;
        function GetPadding: TPadding;
        function GetOutsetShadow: TOutsetShadow;
     protected
        property Background: TBackground read GetBackground
           description 'Specifies the background for the control''s client
area';
        property Caption: String read GetCaption write SetCaption
           description 'Specifies the caption of the control';
        property Font: TFont read GetFont
           description 'Specifies the font for the control';
        property InsetShadow: TInsetShadow read GetInsetShadow
           description 'Specifies the inset shadow for the control''s
client area';
        property Padding: TPadding read GetPadding
           description 'Specifies the padding for the control''s client
area';
        property OutsetShadow: TOutsetShadow read GetOutsetShadow
           description 'Specifies the outset shadow for the control';
        function GetClientElement: TElement; override;
        procedure CreateInterfaceElements; override;
        procedure InitializeProperties; override;
        procedure UpdateInterfaceState; override;
     end;

  {$INTERFACE TGroupPanel}

  TGroupPanel = class(TGroupPanelControl)
     protected
        procedure InitializeProperties; override;
        function GetInterfaceClassName: String; override;
     published
        property Top;
        property Left;
        property Height;
        property Width;
        property AlwaysOnTop;
        property Background;
        property Caption;
        property Constraints;
        property Cursor;
        property DisplayOrder;
        property Font;
        property InsetShadow;
        property Layout;
        property LayoutOrder;
        property Margins;
        property Opacity;
        property Padding;
        property TabOrder;
        property TabStop default True;
        property Visible;
        property OnShow;
        property OnHide;
        property OnMove;
        property OnSize;
        property OnClick;
        property OnDblClick;
        property OnMouseDown;
        property OnMouseMove;
        property OnMouseUp;
        property OnMouseEnter;
        property OnMouseLeave;
     end;

As you can see, almost all of the code is just design-time window-dressing
about which properties to publish, etc., and the rest is just wrappers
around TElement properties.  Creating the interface is all done visually
with the interface designer.  The productivity for component developers is
much improved over what you have with JS, or even Delphi.  That was one of
the primary goals of EWB 2 - components/controls *must* be very easy to
create.  Take event dispatching, for example.  With EWB 2, you can create
sub-controls for use in other controls (think of the form
minimize/restore/close buttons), and EWB will *automatically* dispatch any
UI events to the sub-control instead of the outer control.  All while still
automatically knowing that the outer control is *the* control in terms of
run-time/design-time interaction.  For example, here are the panel/form
button declarations:

  {$INTERFACE TPanelMinimizeButton}
  {$INTERFACE TPanelRestoreButton}
  {$INTERFACE TPanelCloseButton}

  TPanelButton = class(TControl)
     private
        function GetPanel: TPanelControl;
     protected
        property Panel: TPanelControl read GetPanel;
        procedure InitializeProperties; override;
     published
        property Visible;
     end;

  TPanelMinimizeButton = class(TPanelButton)
     protected
        function GetInterfaceClassName: String; override;
        function DoClick: Boolean; override;
     end;

  TPanelRestoreButton = class(TPanelButton)
     protected
        function GetInterfaceClassName: String; override;
        function DoClick: Boolean; override;
     end;

  TPanelCloseButton = class(TPanelButton)
     protected
        function GetInterfaceClassName: String; override;
        function DoClick: Boolean; override;
     end;

There isn't any huge amount of code dedicated to "wiring-up" the buttons
into the panel/form.  You simply just override the DoClick and tell EWB what
to do when someone clicks on the button.  Furthermore, you can make all of
this work interactively at design-time without doing *anything* different in
terms of your code.

My guess would be that, apart from fairly complex drawing/charting or HTML
editors, 80-90% of the JS controls out there can be done much easier in
native EWB.  And, more importantly, this is code that *you* can customize
(in most cases, visually) in any way that you want, which is important when
you find yourself staring at 10k of JS/HTML/CSS code that you've never
looked at before, and are trying to figure out why something doesn't work
right in your application.

<< So, one question, for someone not going to be on the early experience
programme: Can I pre-order? >>

Not yet, but we'll probably start taking pre-orders that will give you
access to the product at the "product is done, but docs are being worked on"
stage.  It all depends upon whether we'll have time for public testing or
not, which will kind of depend upon what happens with some earlier private
testing.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 18 2014 5:16 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Raul,

<< I assume native controls will still be be supported runtime and hopefully
better than v1. If at design time there is a generic container where the JS
component goes runtime is best i'm hoping. >>

Yes, you can wrap the underlying elements in a way that serves as the
middleman between the JS control and the EWB control.  You don't *have* to
do it this way, but it's the way we do it with other DOM elements (in
general, there is a lot of flexibility in how you can use the new UI
features).  The UI layer has a whole change management scheme that allows
one to include *any* change in a batch of changes (BeginUpdate/EndUpdate),
so that the change management can be extended to support any type of change.
For example, you can see this with the TLinkElement that we implemented:

{ TLinkElement }

function TLinkElement.CreateDOMElement: THTMLElement;
begin
  Result:=CreateDispatchableElement(Self,HTML_TAG_LINK);
end;

procedure TLinkElement.Initialize;
begin
  DOMElement.setAttribute(HTML_ATTR_TARGET,HTML_VALUE_BLANK);
end;

function TLinkElement.RequiresUpdate(AChanges: TSet): Boolean;
begin
  Result:=inherited RequiresUpdate(AChanges);
  if (not Result) then
     begin
     if AChanges.Exists(scLinkURLChanged) or
        AChanges.Exists(scLinkWindowChanged) then
        Result:=True;
     end;
end;

procedure TLinkElement.Update(AChanges: TSet);
begin
  inherited Update(AChanges);
  if Assigned(DOMElement) then
     begin
     if AChanges.Exists(scLinkURLChanged) then
        DOMElement.setAttribute(HTML_ATTR_HREF,FURL);
     if AChanges.Exists(scLinkWindowChanged) then
        begin
        if FNewWindow then
           DOMElement.setAttribute(HTML_ATTR_TARGET,HTML_VALUE_BLANK)
        else
           DOMElement.removeAttribute(HTML_ATTR_TARGET);
        end;
     end;
end;

procedure TLinkElement.SetNewWindow(Value: Boolean);
begin
  if (Value <> FNewWindow) then
     begin
     FNewWindow:=Value;
     DoChanged(scLinkWindowChanged);
     end;
end;

procedure TLinkElement.SetURL(const Value: String);
begin
  if (Value <> FURL) then
     begin
     FURL:=Value;
     DoChanged(scLinkURLChanged);
     end;
end;

You could do the same for an external JS control, thus allowing you to have
the outer TControl be notified when things change with the underlying JS
control.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 18 2014 5:19 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< I scoured the video for hints of touch support, but didn't see any, which
is probably because it was aimed at component developers. Does EWB 2 have
touch events in the first release? >>

It will.  They're not done yet, though.

<< It also struck me that I aim to build a component, but it will be forever
private (key part of our core competence that I don't want to give away!).
Would that exclude me from the early programme? It may be that other
commitments stop me playing anyway, but I might spend time over Christmas
exprimenting on what I want to build. >>

Officially, yes, that would exclude you.  However, please send Sam and email
and I'll make sure that you're on the list.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 18 2014 5:20 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Looks nice, looks impressive and I was following until you started
consuming things. >>

It's a little hard to follow until you start playing around with it. Smile
You can change things around and see them re-arrange at design-time, so that
gives you an idea of how the various layout properties interact.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 18 2014 5:22 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

<< Tim, this is really good news for all of us!  Can't wait to test it, to
create some components, and of corse to give the new life of our language.
After watching promo video i think you took the right direction. >>

Thanks, much appreciated.  The web application world needs some more
innovation on the RAD side of things, so hopefully this will help move
things in that direction.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 18 2014 7:22 PMPermanent Link

Steve Gill

Avatar

Hi Tim,

This looks very impressive. I can't wait until the release. Maybe it's time for me to start doing component development again.

= Steve
Wed, Nov 19 2014 2:16 AMPermanent Link

Ivan Mihailov

Tim,

what you do is amazing!

Congratulations!
Wed, Nov 19 2014 4:13 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

> << It also struck me that I aim to build a component, but it will be
> forever private (key part of our core competence that I don't want to
> give away!). Would that exclude me from the early programme? It may
> be that other commitments stop me playing anyway, but I might spend
> time over Christmas exprimenting on what I want to build. >>
>
> Officially, yes, that would exclude you.  However, please send Sam
> and email and I'll make sure that you're on the list.

I've emailed, and may start with my WebBuilder 1 "components" that you
can see at
http://www.banxia.com/resources/connect/userguide/index.html?rating.htm
which might be generally useful to others. Depends on how much time I
get really, as ever.

--

Matthew Jones
Wed, Nov 19 2014 5:50 AMPermanent Link

Sergionn

Also send sent a request about to start component development.
Have some ideas, energy and design experience to make EWB not only the alternative of Sencha Space and ect,
but a new chance for Object Pascal, which Firemonkey and SmartMobile studio obviously couldn't become.
Wed, Nov 19 2014 6:36 AMPermanent Link

Robert Devine

Looks impressive Tim - sorry to sound like a stuck record but does the
v2 compiler have interfaces and will I be able to use .pas files
together with IFDEFs?

Thanks, Bob
« Previous PagePage 2 of 4Next Page »
Jump to Page:  1 2 3 4
Image