I thought that it might be interesting for some of the newer EWB users to see what can be achieved with the product in a relatively short timeframe.

Our most recent application is a very fully-featured front-end to a REST-based collaborative information server. This has been created entirely in EWB and functions on desktop and mobile browsers (utilising some dynamic UI adjustment). Some screenshots can be found on the Castrum website, specifically in the features section:

http://www.castrum.co.uk/features

We have other developers in the business utilising either .NET or JS. Typically EWB comes together quicker and executes at least as quickly. Perhaps most importantly, it results in by far the least amount of reported bugs.

The only real issues are (a) the need to occasionally step outside of the EWB framework to access things like the "base" elements, but this is becoming less and less of a requirement as it matures, and (b) the lack of support for "flow" of DOM elements. I have yet to play with 1.02 but the new "align" capabilities may go some way to addressing this.

Overall, a real ground-breaker, for us at least.

Mark,

<< I thought that it might be interesting for some of the newer EWB users to
see what can be achieved with the product in a relatively short timeframe.
>>

Thanks Mark - looks great, as always.

BTW, if you get a chance, can you send me a brief email with the list of
things that you have to use external code for ?  I know that you were using
something external for the downloading, but I'd like to see if I can "close
the gap".

I'm finding that doing things directly in EWB is beneficial in two ways:

1) The wrapper code tends to be easier to deal with, such as with the
TCanvas and how one has to deal with gradients/patterns when
stroking/filling.
2) Because the wrapper code is not direct DOM identifier references, it can
all be compressed significantly.  Again, take heavy amounts of canvas method
calls - the EWB version will be significantly smaller when compressed than
if one was to call the canvas element methods directly.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

>>Thanks Mark - looks great, as always.

Appreciated Tim. Users are loving it ......... so far

>>BTW, if you get a chance, can you send me a brief email with the list of
>>things that you have to use external code for ?  I know that you were using
>>something external for the downloading, but I'd like to see if I can "close
>>the gap".

Sure. There are only two areas where I have reverted to external JavaScript:

Uploading. Here I utilise one of the many multi-file uploaders that are available as JS addins. I do this by embedding the uploader within an iFrame and communicating with it via a query string on its URL. Benefits over the EWB mechanism include progress feedback and multiple simultaneous uploads. This all boils down to support for the HTML5 XHR upload extensions. Would be relatively straightforward to get into EWB I guess (and very worthwhile IMHO).

Rich Text Editing. Here I utilise CKEditor, again embedded within an iFrame, but this time with a little of my own external JS (maybe 10 lines max) to set and retrieve its "content". The CKEditor is a significant component in terms of functionality and I imagine that trying to emulate this in EWB would be awkward and probably a waste of time (again just my opinion).  

If you need more info or screenshots just let me know.

>>I'm finding that doing things directly in EWB is beneficial......

Well, as I said before, I am finding that my work seems far more stable than the elements developed in .NET and JS by some of the other guys. Their main inherent advantage continues to be very simple support for "flowing" interfaces. For example, inserting something in the middle of a "list" is painful in EWB (unless I'm missing something) but very simple and slick for these guys (along with the associated smooth scroll open and close animations). Very cool. BUT, and it's a BIG BUT, the EWB advantage seems be be reduced bugs and "funnies" even as the apps scale quite large. The underlying Object pascal structure was designed for writing "proper apps" and the EWB compiler does a great job of producing optimal and SAFE JS.  

Hope that makes sense.

Mark

Mark:


<Rich Text Editing. Here I utilise CKEditor, again embedded within an iFrame, but this time with a little of my own external JS (maybe 10 lines max) to set and retrieve its "content". The CKEditor is a significant component in terms of functionality and I imagine that trying to emulate this in EWB would be awkward and probably a waste of time (again just my opinion).  >


Rich Text Editing is a big requirement for me.  Would you consider posting an example of using the CKEditor?  I would be grateful.

Walter

>>Rich Text Editing is a big requirement for me.  Would you consider posting an example of using the CKEditor?  I >>would be grateful.

No problem. Basically it works a bit like this:

- Create an HTML file (see bottom of post) to instantiate a CKEditor instance and provide some access to its content. You may like to place this in your output folder so that it gets deployed along with your project.

- Configure and download an appropriate CKEditor deployment from their website. Again you may like to place this (folder) in your output folder.  

- Use a TPage to load your HTML file at runtime.

- At runtime, set the TPage URL property to the HTML file address. This will load the HTML and setup the CKEditor instance (it actually does this by taking over a simple text area defined within the HTML).

- Once the TPage has loaded the HTML file (trap the EWB event accordingly) you can set the content of the CKEditor to your desired HTML string using a JS function in your HTML file (my function is called castrumSetCKEditorContent)

- You can subsequently retrieve the content of the CKEditor as an HTML string using another JS function in your HTML file (my function is called castrumGetCKEditorContent).

That is pretty much it. Works well for me, although I'm not a JS guy so I guess there may be a more elegant mechanism. Further code below for some of the more tricky EWB <-> JS bits:

Here is the HTML file that I use:
-------------------------------------------------------------------------------------------------------------------------------------------------------------

<!DOCTYPE html>

<html lang="en" xmlns="" name="http://www.w3.org/1999/xhtml">">http://www.w3.org/1999/xhtml">
   <head>
      <meta charset="utf-8" />
      <title></title>
      <script src="../CoreLib/jquery/jquery-1.8.1.min.js"></script>
      <script type="text/javascript" src="../corelib/utils.js"></script>
      <script type="text/javascript" src="ckeditor/ckeditor.js" ></script>
   </head>

   <body style="margin: 0px; padding: 0px;">
      <textarea id="castrumCkEditor" style="width: 100%; border: 0px;"></textarea>
   
      <script type="text/javascript">

         // Page is loaded so set function to call when CKEDITOR is ready (this will remove border and maximize it)
      
         $(document).ready(function ()
         {
            var editor = CKEDITOR.replace("castrumCkEditor");
      
            CKEDITOR.on('instanceReady', function(e)
            {
               $('#cke_castrumCkEditor').css('border',0);
               e.editor.execCommand('maximize');
            });
          })

         // Get the content of the editor as HTML from EWB
         
         function castrumGetCKEditorContent()
         {
            var data = CKEDITOR.instances['castrumCkEditor'].getData();
            return data;
         }
         
         // Set the content of the editor as HTML form EWB
         
         function castrumSetCKEditorContent(content)
         {
            $("#castrumCkEditor").val(content);
         }
         
         // Set the editor to read only from EWB (flakey in current CKEditor version)
         
         function castrumSetCKEditorReadOnly()
         {
            CKEDITOR.instances['castrumCkEditor'].setReadOnly(true);
         }

   </script>
   </body>
</html>

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Here is the JS that I use to access the functions inside the HTML file. This is required since hosting the CKEditor in a TPage will create an iFrame. You need to add it as an external file in your project manager:

// Locate an iFrame by name and return reference to it

function getIframeByName(frameName)
{
   var iframes = document.getElementsByTagName("iframe");
   for (var i = 0; i < iframes.length; ++i)
   {
       if (iframes[i].name == frameName)
      {
           return iframes[i];
       }
   }
   throw new Error('Unable to locate iFrame by name');
}

// Return the content of the CKEditor called 'castrumCkEditor' within the iFrame 'frameName'

function getEditorContentForFrame(frameName)
{
   return getIframeByName(frameName).contentWindow.castrumGetCKEditorContent();
}

function setEditorContentForFrame(frameName,content)
{
   getIframeByName(frameName).contentWindow.castrumSetCKEditorContent(content);
}

function setEditorReadOnlyForFrame(frameName)
{
   getIframeByName(frameName).contentWindow.castrumSetCKEditorReadOnly();
}

-------------------------------------------------------------------------------------------------------------------------------------------------------------

And finally, you'll need to wrap theses JS functions with some EWB external defs as follows:

 external function getEditorContentForFrame(const frameName: string): string;
 external function setEditorContentForFrame(const frameName: string; const content: string);
 external function setEditorReadOnlyForFrame(const frameName: string);

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Good luck. It's a bit tricky but well worth the effort.

Cheers
Mark

Mark:

Thank you!  I'm not a JS guy ... and just learning the nuances of the web world.

Did I say Thanks!  

Walter

>>Thank you!  I'm not a JS guy ... and just learning the nuances of the web world.

No worries. Same for me, but maybe a few months ahead of you in the cycle. Old dog, new tricks for me I'm afraid!

Mark,

<< Sure. There are only two areas where I have reverted to external
JavaScript: >>

Great, thanks very much.

<< Well, as I said before, I am finding that my work seems far more stable
than the elements developed in .NET and JS by some of the other guys. Their
main inherent advantage continues to be very simple support for "flowing"
interfaces. For example, inserting something in the middle of a "list" is
painful in EWB (unless I'm missing something) but very simple and slick for
these guys (along with the associated smooth scroll open and close
animations). >>

With the new docking in 1.02, the only thing missing for proper "flow" of
docked controls is an InsertControl method for the container class that will
allow you to set the control index, which subsequently controls how the
controls are docked (in which order).  I just modified the framework to
allow for docking of forms into the desktop, so the next build will allow
you to do that also.

Tim Young
Elevate Software
www.elevatesoft.com

>>With the new docking in 1.02, the only thing missing for proper "flow" of
>>docked controls is an InsertControl method for the container class that will
>>allow you to set the control index, which subsequently controls how the
>>controls are docked (in which order).  I just modified the framework to
>>allow for docking of forms into the desktop, so the next build will allow
>>you to do that also.

Christmas is coming early!
Yeehaa!