I would like to wish a Merry Christmas to all the readers of this blog. I hope that this has been a good year for you and that 2009, despite all the gloomy predictions, will be an even better year.
I hope you have enjoyed reading this blog at least half as much as I have enjoyed writing it. In the coming months I am sure there will be plenty of stuff for me write about and consequently for you to read, as Morfik 2.0 has been getting more and more interest from people all over.
In the barely two months since the release of Morfik 2.0 I have been contacted by companies from several different sectors that want to get information on if it is possible to achieve this or that with Morfik or how to do it. Some of these companies have already hired staff and started new projects based on the Morfik 2.0 platform and I feel that this is but the start of a very interesting period for Morfik.
So, take a few days to relax and have a nice holiday season with your family and friends. Recharge your batteries and jump right into your 2009 projects.
Merry Christmas!
Thursday, December 25, 2008
Saturday, December 20, 2008
For Basic developers that want do Ajax: Morfik Basic
Morfik Basic is one of the language syntaxes which are supported by Morfik AppsBuilder 2.0. More specifically it is the language syntax used by Morfik BX which is one of the versions of AppsBuilder 2.0 released last month.
If you are a Basic user, this is good news for you. Morfik Basic was created to allow Basic developers to have easy access to the advanced Ajax application building capabilities of Morfik AppsBuilder. A lot of effort went into making sure that the extensions necessary so that the Basic language could reflect all the capabilities of the underlying Morfik semantics did not seem "foreign" to the Basic developer.
For example, in order to implement in-code documentation, Morfik relies on multi-line comments which are not available in traditional Basic. In adding this feature to Morfik Basic it was tapped from the C family of languages as Microsoft is currently the primary developer of a Basic language and it was reasoned that if they were to add such a feature to the language they would probably use their C# syntax.
For adding pointer support, on the other hand, it was decided that since C# has no such support, falling back to C++ or C would not be a good idea. In that respect it was decided to base the syntax in the ByRef and ByVal keywords that are used to specify how parameters are passed to Functions and Subs in Visual Basic. Reference parameters are, in essence, pointers and this seemed like a logical way of doing it, even if a bit verbose. The following is an example of a common declaration of a variable of the Integer type followed by a declaration of a variable that is a pointer to an Integer.
In order to actually the use the integer value that is referenced by this pointer you need to dereference the variable which is done using the syntax you can see in the following line:
Though it seems a bit on the lengthy side, it seems to fit in with the Basic language practice and is actually pretty clear about what the code is doing. Considering that at application level there is very little pointer usage in Morfik and since there are no pointers in Basic it seemed better to write a few characters more every once in a while than to add a cryptic operator for the sake of saving some keystrokes.
In general I believe that Basic developers should feel right at home with the language, though like everybody else, they will still need to learn the Morfik Framework.
If you are a Basic user, this is good news for you. Morfik Basic was created to allow Basic developers to have easy access to the advanced Ajax application building capabilities of Morfik AppsBuilder. A lot of effort went into making sure that the extensions necessary so that the Basic language could reflect all the capabilities of the underlying Morfik semantics did not seem "foreign" to the Basic developer.
For example, in order to implement in-code documentation, Morfik relies on multi-line comments which are not available in traditional Basic. In adding this feature to Morfik Basic it was tapped from the C family of languages as Microsoft is currently the primary developer of a Basic language and it was reasoned that if they were to add such a feature to the language they would probably use their C# syntax.
For adding pointer support, on the other hand, it was decided that since C# has no such support, falling back to C++ or C would not be a good idea. In that respect it was decided to base the syntax in the ByRef and ByVal keywords that are used to specify how parameters are passed to Functions and Subs in Visual Basic. Reference parameters are, in essence, pointers and this seemed like a logical way of doing it, even if a bit verbose. The following is an example of a common declaration of a variable of the Integer type followed by a declaration of a variable that is a pointer to an Integer.
Dim I As Integer
Dim newX As Ref Integer
In order to actually the use the integer value that is referenced by this pointer you need to dereference the variable which is done using the syntax you can see in the following line:
newY = DeRef newX +5
Though it seems a bit on the lengthy side, it seems to fit in with the Basic language practice and is actually pretty clear about what the code is doing. Considering that at application level there is very little pointer usage in Morfik and since there are no pointers in Basic it seemed better to write a few characters more every once in a while than to add a cryptic operator for the sake of saving some keystrokes.
In general I believe that Basic developers should feel right at home with the language, though like everybody else, they will still need to learn the Morfik Framework.
The strengths of an HTML based application
Recently, in visiting a website which was entirely built with Flash, I was reminded of some discussions I had about the weaknesses of such an approach and consequently of the corresponding strengths of doing it all in HTML.
This really hit me because of a small thing. I usually scroll through pages by using the mouse's scroll wheel and was really unhappy because for some reason I was being able to do it. When accidentally I moved the mouse a bit to the side, and thus outside the area covered by the flash control, and tried it for the nth time, it worked. It was then that I noticed that the scroll wheel information doesn't get through from the flash control to the underlying browser. I guess I must have seen this before, but I just did not register it because that particular page wasn't trying to show me a large quantity of information about a company.
The fact is that even though you can nicely fit in a flash control into a website for displaying a video or an animation, and you can make it look like it really fits in there, it is never really the same as what is around it. This can be okay, and actually work really well when the goal of the website is directly related to the usage of flash, such as is the case with YouTube or the Morfik Learning Center with its videos. When the website, however, is just a corporate presence or when it is an application that displays large quantity of data to the user, I feel that this not-quite-browser behaviors of flash get in the way.
Don't get me wrong. I am not against the use of flash, where appropriate, and I believe that as far as desktop applications go Adobe has something good going with its Air platform, but there is such a thing as trying to use a hammer where a screwdriver is more appropriate.
When you build your application entirely on the standard content that is handled by the browser (HTML, CSS, etc) and use Ajax for interactivity, it just "feels" more natural, even when you are doing things which were not so natural for browsers some years ago. Again, a good example of this is GMail which does a lot of page morphing which was not so common before it came along, but which never feels like anything but a web page.
The fact that the application does not require a plugin is also nice, as there places, speacially some schools, that block the installation of plugins. This might not be much of an issue for many commercial usages, but then for some people it might just make the application unavailable.
This is a discussion that falls into the same category as the one about how web applications should look. There isn't a right answer, there are just opinions.
This really hit me because of a small thing. I usually scroll through pages by using the mouse's scroll wheel and was really unhappy because for some reason I was being able to do it. When accidentally I moved the mouse a bit to the side, and thus outside the area covered by the flash control, and tried it for the nth time, it worked. It was then that I noticed that the scroll wheel information doesn't get through from the flash control to the underlying browser. I guess I must have seen this before, but I just did not register it because that particular page wasn't trying to show me a large quantity of information about a company.
The fact is that even though you can nicely fit in a flash control into a website for displaying a video or an animation, and you can make it look like it really fits in there, it is never really the same as what is around it. This can be okay, and actually work really well when the goal of the website is directly related to the usage of flash, such as is the case with YouTube or the Morfik Learning Center with its videos. When the website, however, is just a corporate presence or when it is an application that displays large quantity of data to the user, I feel that this not-quite-browser behaviors of flash get in the way.
Don't get me wrong. I am not against the use of flash, where appropriate, and I believe that as far as desktop applications go Adobe has something good going with its Air platform, but there is such a thing as trying to use a hammer where a screwdriver is more appropriate.
When you build your application entirely on the standard content that is handled by the browser (HTML, CSS, etc) and use Ajax for interactivity, it just "feels" more natural, even when you are doing things which were not so natural for browsers some years ago. Again, a good example of this is GMail which does a lot of page morphing which was not so common before it came along, but which never feels like anything but a web page.
The fact that the application does not require a plugin is also nice, as there places, speacially some schools, that block the installation of plugins. This might not be much of an issue for many commercial usages, but then for some people it might just make the application unavailable.
This is a discussion that falls into the same category as the one about how web applications should look. There isn't a right answer, there are just opinions.
Thursday, December 18, 2008
Morfik 2.0 needs a "clean" theme
Having experimented with several of the built in themes in Morfik 2.0 I came to the conclusion that it should have a theme with more of a "clean" look. I really like the some of the themes that are bundled, including the one called "Default" which, not surprisingly, is the default one, but I really like to build web applications which have more of a clean look to them.
I prefer to work with white backgrounds, light and bright colors and add some visual effects (sparingly) for effect. I get this feeling that when you use too much of the visual effects at the same time, they loose a bit of their appeal, as they kind of "interfere" with each other.
Most of the themes that are bundled are just a bit too "rich" on visual effects to be to my liking and I really think that a "plainer", "cleaner" theme should be added to the built-in theme collection.
Of course, you can create your own theme with its own set of visual effects, colors, fonts, etc. I have done exactly this, twice already, but I'm not yet up to the same level of polish as the bundled themes display.
I prefer to work with white backgrounds, light and bright colors and add some visual effects (sparingly) for effect. I get this feeling that when you use too much of the visual effects at the same time, they loose a bit of their appeal, as they kind of "interfere" with each other.
Most of the themes that are bundled are just a bit too "rich" on visual effects to be to my liking and I really think that a "plainer", "cleaner" theme should be added to the built-in theme collection.
Of course, you can create your own theme with its own set of visual effects, colors, fonts, etc. I have done exactly this, twice already, but I'm not yet up to the same level of polish as the bundled themes display.
Wednesday, December 17, 2008
Morfik releases the first update for AppsBuilder 2.0
Morfik released today an update to AppsBuilder 2.0. The new build (2.0.5.18) fixes a number of bugs that were still present when the original AppsBuilder 2.0 was released, just last month.
The release of this new build just about one month after the introduction of the first 2.0 release shows that Morfik is working hard on the continuous development and stabilization of the product. Apart from fixing a sizeable number of bugs this build reintroduces the a FileUploader control that is non-flash based, as requested by many users.
From a full day of using build 2.0.5.18 I can say that it represents a clear improvement over the previously available build.
The release of this new build just about one month after the introduction of the first 2.0 release shows that Morfik is working hard on the continuous development and stabilization of the product. Apart from fixing a sizeable number of bugs this build reintroduces the a FileUploader control that is non-flash based, as requested by many users.
From a full day of using build 2.0.5.18 I can say that it represents a clear improvement over the previously available build.
Monday, December 15, 2008
Web based applications should look like websites
The title for this post, obviously, reflects my opinion, but it is not just a wild guess. Through the years I have worked with a lot of different web based applications, from many different vendors. I have seen a great many people start using them and watched how the process evolves.
Most people prefer to access applications through the browser, rather than using clunky desktop interfaces. Of course, not all desktop interfaces are clunky and many applications are better served by a traditional native interface. At this time I would say that office productivity tools are one of the main groups to fit in that category.
Most business applications however, can be implemented gracefully as web based applications and the use of Ajax and such techniques allows for the creation of very responsive interfaces. Recently I took part in a discussion about having web applications that mimic desktop applications or that look like websites. I consider this a matter of personal choice, but I believe that web applications should look like websites. Right now, I'm writing this article inside a browser and I am quite happy with the interface that is provided. It behaves as I expect and thought I would not want to write a book in this interface, it feels quite okay for writing a blog post.
The fact is that I have never seen a web based application that mimicked a desktop interface and that felt natural. Quite the contrary, actually. They normally feel slow and unresponsive. It might be due to the fact that you expect something that looks like a web page to have small delays in responding to your commands and when it behaves better than that it is a nice surprise, but the opposite is true for something that looks like a desktop application. If something looks like a normal windows application, you expect it to behave like one. In this case, even the slightest delay will fell odd and make the application seem to be unresponsive.
The more logic you implement on the browser side, the more responsive your application tends to be. (As long as you know what you are doing. :-) ) In building an application that will be available through the Internet, it is inevitable that there will be a slight lag anytime you need to do a round-trip to the server to obtain data. This is one of the main reasons why applications that try to simulate a regular desktop application are going to have a hard time being appreciated by end-users.
Most people prefer to access applications through the browser, rather than using clunky desktop interfaces. Of course, not all desktop interfaces are clunky and many applications are better served by a traditional native interface. At this time I would say that office productivity tools are one of the main groups to fit in that category.
Most business applications however, can be implemented gracefully as web based applications and the use of Ajax and such techniques allows for the creation of very responsive interfaces. Recently I took part in a discussion about having web applications that mimic desktop applications or that look like websites. I consider this a matter of personal choice, but I believe that web applications should look like websites. Right now, I'm writing this article inside a browser and I am quite happy with the interface that is provided. It behaves as I expect and thought I would not want to write a book in this interface, it feels quite okay for writing a blog post.
The fact is that I have never seen a web based application that mimicked a desktop interface and that felt natural. Quite the contrary, actually. They normally feel slow and unresponsive. It might be due to the fact that you expect something that looks like a web page to have small delays in responding to your commands and when it behaves better than that it is a nice surprise, but the opposite is true for something that looks like a desktop application. If something looks like a normal windows application, you expect it to behave like one. In this case, even the slightest delay will fell odd and make the application seem to be unresponsive.
The more logic you implement on the browser side, the more responsive your application tends to be. (As long as you know what you are doing. :-) ) In building an application that will be available through the Internet, it is inevitable that there will be a slight lag anytime you need to do a round-trip to the server to obtain data. This is one of the main reasons why applications that try to simulate a regular desktop application are going to have a hard time being appreciated by end-users.
Tuesday, December 9, 2008
Extending your gradient options in Morfik 2.0
Morfik AppsBuilder 2.0 introduced a large number of visual effects that can be applied to controls and Form bands. Among these effects is the gradient effect, which is used frequently in a lot of web pages and applications.
Despite the fact that Morfik provides a large number of options for the gradient effect, it does restrict them somewhat when the control or band you are formatting is using a very dark or very light color. The form designer only offers you dark gradient options when the control is using a light color and light options went it is using a dark color. This can be a bit limiting when, for example, you want to have a gradient that goes from a light color to an even lighter one.
You can work around this limitation by temporarily altering the color of the control or band to a darker or lighter color (depending on the case) and then selecting the specific gradient option you want to use. When you return to the original color, the gradient selection is retained by the control or band.
It is probable that this limitation will removed by Morfik in a future release, as it is not a technical limitation and it makes little sense to take away formatting options that the product already supports. In the mean time, you can get around this small limitation by using this simple workaround.
Despite the fact that Morfik provides a large number of options for the gradient effect, it does restrict them somewhat when the control or band you are formatting is using a very dark or very light color. The form designer only offers you dark gradient options when the control is using a light color and light options went it is using a dark color. This can be a bit limiting when, for example, you want to have a gradient that goes from a light color to an even lighter one.
You can work around this limitation by temporarily altering the color of the control or band to a darker or lighter color (depending on the case) and then selecting the specific gradient option you want to use. When you return to the original color, the gradient selection is retained by the control or band.
It is probable that this limitation will removed by Morfik in a future release, as it is not a technical limitation and it makes little sense to take away formatting options that the product already supports. In the mean time, you can get around this small limitation by using this simple workaround.
Sunday, December 7, 2008
Web development for desktop developers
Morfik AppsBuilder completely changes the rules of the Web development for people with experience in desktop software development. This was one of the first that jumped at me when I saw my first demo of AppsBuilder.
Before Morfik came along with its compiler and development environment, Web development was mostly centered around text editors and scripting which were intermixed, but loosely coupled. Morfik changes all that by bringing to Web development the same RAD philosophy which has become a huge success for the development of desktop applications on Windows.
RAD or Rapid Application Development is a technique where you design the interface of your application visually and add glue code through the use of an event driven model. The event model was already present in the browser's underlying DOM (Document Object Model) and JavaScript engines and is well integrated into Morfik's visual designer.
The bottom line is that a AppsBuilder allows a developer who is familiar with a tool such as Delphi or Visual Basic to not only become productive quickly, but to actually outdo an experienced Web developer that uses conventional tools.
Before Morfik came along with its compiler and development environment, Web development was mostly centered around text editors and scripting which were intermixed, but loosely coupled. Morfik changes all that by bringing to Web development the same RAD philosophy which has become a huge success for the development of desktop applications on Windows.
RAD or Rapid Application Development is a technique where you design the interface of your application visually and add glue code through the use of an event driven model. The event model was already present in the browser's underlying DOM (Document Object Model) and JavaScript engines and is well integrated into Morfik's visual designer.
The bottom line is that a AppsBuilder allows a developer who is familiar with a tool such as Delphi or Visual Basic to not only become productive quickly, but to actually outdo an experienced Web developer that uses conventional tools.
Subscribe to:
Posts (Atom)
Posts
