Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 21 to 30 of 45 total |
General Feedback |
Mon, Dec 12 2011 8:34 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Dec 13 2011 9:52 AM | Permanent Link |
Robert Devine | 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. > |
Tue, Dec 13 2011 10:01 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Apr 20 2012 3:18 AM | Permanent Link |
Leslie | 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 |
Fri, Apr 20 2012 4:38 AM | Permanent Link |
Ronald | 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 |
Fri, Apr 20 2012 11:24 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Apr 20 2012 1:21 PM | Permanent Link |
Leslie | 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 |
Fri, Apr 20 2012 8:48 PM | Permanent Link |
Dominique Willems | 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. |
Fri, Apr 20 2012 11:25 PM | Permanent Link |
Steve Gill | << 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. |
Sat, Apr 21 2012 2:35 AM | Permanent Link |
Leslie | "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. |
« Previous Page | Page 3 of 5 | Next Page » |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |