Ron,

<< : This is certainly true - but then, there are some JS libraries that do
things really well and are wonderfully optimized - there are very big web
sites working with these - so - like anything else - if you choose your
stuff carefully - there are wonderful options out there. >>

Yes, but you're not understanding what I'm saying.  The fact that the
existing JS libraries are good, wonderful, etc. is irrelevant.  EWB is
specifically designed to *not* use those frameworks and to have a framework
of its own.  There are other options available already, and have been for
some time, like ExtJS that allow you to use those frameworks/libraries with
the existing Delphi IDE.  The whole design of EWB goes out the window once
you start using other JS frameworks - the theming, the control hierarchy
that allows you to iterate controls on forms/containers/panels, tabbing
control, component ownership, etc.  There is no point to using EWB if you
don't intend to use the framework.  Theoretically, I guess you could use the
compiler by itself to just generate JS that references these other
frameworks, but you're really throwing out the best part of the product -
the IDE/controls.

<< : Again - this is true, but if you use libraries that are properly using
closures - this is a no-issue - as they limit the use of global scope
variables and allow you to override it. >>

The namespaces used, in general, could conflict with any number of
identifiers used in a compiled EWB application.

<< : - I plan to look at this unit - but at the end of the day - they both
create code that runs down to the same DOM managed by the browser - so if
you pay attention to what you are doing - it should not matter. >>

Hooking that code into EWB involves a defined interface so that the EWB
compiler can, at the very least, do a proper compilation and make sure that
the code is used properly.  Again, if you look at the WebDOM unit you'll see
what I'm talking about.

As for "paying attention to what you're doing", yes, that is true.  However,
it would be very easy to use jQuery to overwrite some inline style
information on any EWB control, and subsequently cause it to be out of synch
with what the framework *thinks* is set for the control.  Much of the EWB
control information is one-way - the control information is stored in the
control instance, and is then applied to the DOM as an inline style.

<< : Again - will look at this - but there are some world-class widget out
there that it would be a shame if we can not use them - especially if the
way they are instantiated is rather simple and can be done via code only. >>

Certain types of external JS widgets, such as Google Maps, would be useful
to use with EWB.  What I'm talking about is trying to add one control out of
an entire framework.  You'll end up carting around the entire framework, and
you'll blow the size of the application out of the water and make it
unusable because of the load time.  The size of JS source is such that you
can't use a bunch of frameworks.

<< All I am saying is that if there is a way for us to "escape" into
javascript mode - when possible, it will allow some of us to take the tool
to a higher level given our investment in other technologies. >>

WebDOM - check it out.

<< I would really hope that something like the mentioned "javascript" block
is made available - because it would be close to a trivial implementation on
your side - and would be really useful for those of us that are willing to
get our hands dirty. >>

There's no way that this can be done.  It simply wouldn't work since your
hand-coded JS has no way of knowing what on earth everything (objects,
variable names, etc.) is being emitted as, especially when compression is
turned on in the compiler.  What you're describing would only work if you're
putting in complete functions/procedures, or object implementations.  And,
for that, I refer you back to the above (WebDOM).

<< Just like Delphi allows you to get into assembly code if you insist and
you can call Win-API code from managed code in .NET... >>

That's exactly how it works now - it's the same as prototyping
procedures/functions for the Windows API, except that you can also prototype
objects and variables.  This how EWB knows how to call/use the prototyped
code.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ok thanks. What about an in-line include? I've seen this used in some
third party classes and it would allow me to create stubs for non-visual
code - e.g. I have various stats methods and I'd like to use a subset of
these in EWB. So I could have two different class definitions with the
original descending from TPersistent in Delphi and the other from
TObject in EWB, both referencing the same in-line stub.

Cheers, Bob


On 13/12/2011 01:14, Tim Young [Elevate Software] wrote:
> Bob,
>
> << What about the possibility of linking in external .pas files for
> non-visual classes - is that something reasonable? >>
>
> You can do that now - you aren't just restricted to the framework source
> (.wbs files) that comes with EWB. Also, the reason for the .wbs file
> extension is that the Object Pascal that is used is not entirely the
> same as with normal Object Pascal, so to avoid any confusion or the
> possibility of "normal" Delphi units getting picked up by accident by
> the compiler/search paths I used a different file extension.
>

Bob,

<< Ok thanks. What about an in-line include? I've seen this used in some
third party classes and it would allow me to create stubs for non-visual
code - e.g. I have various stats methods and I'd like to use a subset of
these in EWB. So I could have two different class definitions with the
original descending from TPersistent in Delphi and the other from TObject in
EWB, both referencing the same in-line stub. >>

Hmm, interesting, I'll have to think through the ramifications of such a
change, although I can't think of anything bad about it off the top of my
head.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

this is a very interesting conversaiton. It really helps to understand your perspective. And  it is a good one,  On the long run EWB will be  a very well optimized full featured  framework. Exactely what I am looking for. But untill EWB matures it could use some sort of intermediate solution to be useful for real development. Does it effect your goals if some sort of compromize is allowed? It is speed vs real life usability. I really like the speed of EWB this far. Even on mobile. Cigarettes have some serious warnings about the problems they can cause. I could imagine such warning displayed in the IDE for the potentially problematic components.

The choices for me are these:

Do I build my projects on  a solution which is slower and I would not want it on the long run if there is a better solution? ( This would also mean less coding, faster development.)

Or do I start with a framework offering less functionlity at the moment but with long term potential? (This would mean more work on my part.)

I am trying to make the second path working. The question is if it is a viable path at all?  We need google maps (I believe the lack of it is a showstopper for many projects) ... probably a rich text like editor ... I am ready to make the effort and temporary compromize on speed. In my calculation this is the smart decision on the long run.


Cheers,
Leslie
 

I am aiming for the last option. I have great confidence in Elevate and I
really believe in the concept: no special server needed and all code
translated to HTML5.

"Leslie" schreef in bericht
news:682F800C-AED9-4A46-899B-82C0F7615B16@news.elevatesoft.com...

Tim,

this is a very interesting conversaiton. It really helps to understand your
perspective. And  it is a good one,  On the long run EWB will be  a very
well optimized full featured  framework. Exactely what I am looking for.
But untill EWB matures it could use some sort of intermediate solution to be
useful for real development. Does it effect your goals if some sort of
compromize is allowed? It is speed vs real life usability. I really like the
speed of EWB this far. Even on mobile. Cigarettes have some serious warnings
about the problems they can cause. I could imagine such warning displayed in
the IDE for the potentially problematic components.

The choices for me are these:

Do I build my projects on  a solution which is slower and I would not want
it on the long run if there is a better solution? ( This would also mean
less coding, faster development.)

Or do I start with a framework offering less functionlity at the moment but
with long term potential? (This would mean more work on my part.)

I am trying to make the second path working. The question is if it is a
viable path at all?  We need google maps (I believe the lack of it is a
showstopper for many projects) ... probably a rich text like editor ... I am
ready to make the effort and temporary compromize on speed. In my
calculation this is the smart decision on the long run.


Cheers,
Leslie

Leslie,

<< I am trying to make the second path working. The question is if it is a
viable path at all? >>

If it isn't a viable path for you, then you should return the product for a
refund and wait until the product better suits your needs.  I certainly
don't want to make you use a product that doesn't meet your needs, or that
you are uncomfortable using.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Of course you cannot make me use a product I would not want to, but it is exactely the opposite,
I  would really like to use it. In fact I am willing to go the extra mile to be able to do it. I am just trying to make a point that it might be possible to archive your long term goals with the product while giving the developers a chance to archive their short term goals with it too. It seems a suitable solution for this stage of EWB and  a win-win to me.  It is much less work for us to replace the external stuff as the missing peaces from the framework become available than redo the whole thing.

I am truely trying to understand your perspective about this. It might be a good thing if you could wear our shoes just a little.

Cheers,
Leslie

Leslie wrote:
> I am just
> trying to make a point that it might be possible to archive your long
> term goals with the product while giving the developers a chance to
> archive their short term goals with it too.

It is a telltale sign that a developer has spent too much time inside
databases and is in need of a vacation when he keeps using the word
"archive" at every possible opportunity.

<< Leslie wrote:

But untill EWB matures it could use some sort of intermediate solution to be useful for real development. Does it effect your goals if some sort of compromize is allowed? >>

IMHO, I think this would be a bad idea.  I believe Tim should stick to his vision for EWB rather than start introducing compromises that could very likely cause issues later on. For some things, I have found that EWB is not yet at the stage where I can use it, so I'm using other tools in the meantime.  I'll be redeveloping them in EWB later when the time is right.

"Dominique Willems" wrote:


<<It is a telltale sign that a developer has spent too much time inside
databases and is in need of a vacation when he keeps using the word
"archive" at every possible opportunity. >




It can also be a sign of soemone not native English being tired.