What Should Every New eBase User/Developer Know.

[Joe Blake]

I am curious to know form seasoned users,

What Should Every New eBase User/Developer Know?

In other words, I would think at some point in time in using eBase you may think:

Boy, I wish I would have know this six months ago.


Maybe it is an eBase tool or feature you were not aware of. Or perhaps you thought eBase going to work one way, then you did your development and found out eBase didn't work the way you thought.

Just curious.

[Steve]

Hi Joe,

I think that you need to know the basics of:

HTML
CSS
SQL and Databases

Ebase does try its best to aid the user as much as possible by supplying ready made controls, layout containers and wizards for database connectivity. But I think you need some prior knowledge of these areas first.

The rest depends on your final goal and what you are trying to achieve.

You certainly need a good plan to decide the best way to decide to design your Forms and their relationships with other forms.

I like to keep all my forms as basic as possible. They usually consist of one or two pages and I use a menu to navigate each page/form. This maybe either a JSP menu or an Ebase menu component to navigate between forms. I also like to keep all the similar functionality on one form. e.g A customer details form I would have a create/modify page.

Kind regards

Steve

[andyhinds]

It's a small thing but when debugging finding a form in the designer is important, pressing Ctrl+Q brings up the "Element Quick Search" which makes it easy to get to the form you need. Ideal when you have lots of forms spread across many Business Projects.

I think everyone has their own style writing Ebase applications, and certainly naming things consistently and keeping forms and pages organised and simple is important, but this comes with time and practice.

[dvanhussel]

In answer to:

Boy, I wish I would have know this six months ago.

These things come to mind for me (well, luckily for me, not six months ago ):

One thing I learned 'the hard way', is that event-fields can help to keep a project better organised.
What I used to do, is add a script for each event that should be handled (attached to the field with immediate validation). This results in a lot of scripts per project and makes debugging more complicated.

A better way (in my opinion) is to try to have just one script per page. Which is triggerd by an event-field.

With Javascript it is possible to check which form element triggerd the running script. With this it is possible to run specific parts of a script if needed. For example:

if (event.getOwner().elementName=='NEXT_PAGE_BUTTON'){
// Do stuff
}

Also, with Javascript, it is possible to create a library of functions. This adds a lot of flexibilty and can help keeping a project better organised.

Another thing, which is a general best practice in software development, but quite important in Ebase, is to use a consistent naming convention right from the start of a project. It can be quite hard to refactor a complicated Ebase form. In scripts this has been greatly improved by the addition of Javascript and it's code-assist features. But if you want to rename or remove a field in a form, it is (at the moment) not possible to see in which scripts this field is used.

When debugging server side Javascript 'log()' can be used. Because the result of this is not logged when the form is not run from the designer, and to have 'realtime logging', instead we use a simple Javascript function that logs to a form-specific file. This makes debugging more convenient.

(Just before posting this, I realise Andy said a lot of what i say, with a lot less words! : )

I think everyone has their own style writing Ebase applications, and certainly naming things consistently and keeping forms and pages organised and simple is important, but this comes with time and practice.

[Wai]

Where possible, import your fields from resources. Saves a lot of time Mapping your fields. If something does not work, check your mappings!

Use field substitution to pass in dynamic queries into your resource so that they can be re-used in different scenarios. For example &&qry in the where clause.

Re-usability is key:

- Components
- Library Templates
- Shared Script Libraries
- Property Sets
- Resources

Use Ebase locking to manage data integrity when you have multi-user applications.

I find it much simpler and more flexible to create my own navigation buttons rather than using the Next Page / Previous page default navigation buttons. I prefer the on-click event of the button to put my business logic rather than the After page event.

Use the Modifier property to identify and group your field controls so that you can process them all in a few lines of javascript code.

Don't forget about the additional services in the Ebase API:

FileServices
DateServices
LDAPServices

[JoshuaW]

I work with 60 forms, so it is difficult to manage control especially when you have several developers working on some forms.

It pays to follow the naming conventions -
Abbrev script name according to form -> page -> function

ie form called REPORTIT, on page PERSONAL_DETAILS, button onClick

REPORTIT_PD_BUT_ACTION

That way I can group the scripts according to form and page for easy management.

Secondly Database, it is essential to keep it simple. Again apply the same above naming to the column names.

Thirdly try to make GLOBAL components and make sure they are linked to the forms, so you can make future changes and apply on a single click.

Lastly, always make sure your forms have scope for future use. No forms can stay constant. The laws are always changing, so you have to keep changing. If the form is set in mud, you may have to do the form again from scratch, so it pays to have the form future-proofed, thus avoiding having to do it from scratch.

Hope this helps
Josh

[Joe Blake]

IMHO, one of the best ways to judge a software product is to find the product forum and review the forum questions and answers for competency.

Wow. The responses to my initial post are nothing short of fantastic. As a result, I intend on becoming an ebase developer...and will use ebase as the foundation for my companies web site.

I greatly appreciate the time and effort put into these responses, and hope to be able to respond in kind....one day.... in the not to distant future.

That being said, if there is anyone out there in the Southern California, Orange County, Los Angeles County or Riverside County areas...boy do I have a job for you.

[HarryDeBoer]

what can be be the reason(s) that code assist is not working in the javascript serverside editor. I attached a form to Using Form. In most scripts it is working but I have a script were no assist is shown.

[Steve]

Hi Harry,

When you say that the code assist is not working... do you mean that the code assist dialog does not show when "control space" or a dot (.) is entered? Is there an error box shown? Or maybe there is an error in the script file itself that is causing a problem?

Kind regards

Steve

[HarryDeBoer]

Hi Steve,

Could be that there is an error, but no red underlined error is shown in the script. Also the script (a lot of functions in it -it's a shared functions script) worked so far for a while. Yesterday I want to add a function but now the code assist dialog does not show. No error box is shown.

[Steve]

HI Harry,

Could you export your linked form and script and email to support@ebasetech.com and I will take a quick look for you.

Also in the email, please tell me which version of Ebase you are running.

Kind regards

Steve

[HarryDeBoer]

Hi Steve,

sent by e-mail

[Steve]

Hi Harry,

Sorry for the delay. I have had narrowed it down to line 969 of the script:

Code: Select all

return tbl_def.getColumn(nwcolnm).value;

This particular line is causing a problem with the JavaScript parser.

calling:

Code: Select all

return tbl_def.DESC_EXTRADATA01.value;

does not cause this error to occur, but I can see that this is not what you want to do.

You could get round the editor bug by wrapping the line in an eval statement:

Code: Select all

return eval("tbl_def.getColumn(nwcolnm).value");

This is just a workaround for the Ebase JavaScript editor. The runtime will work using either of the return statements.

I will submit this to our bug database.

Kind regards

Steve Upton

[HarryDeBoer]

Hi Steve,

Thanks for the update and the workaround.