Buttons

[Steve James]

Hi, I have a page of a form that has a simple html++ to hide a control when the document is ready. TinyMCE wysiwyg also applies itself to a textarea.

Code: Select all

$( document ).ready(function() {
		$("#NonCouncilIDPanel").hide();
	});

I have an Ebase button that doesn't have an Ebase event but runs a client script from the click event.

The client script runs stuff then executes an Ebase client function

Code: Select all

$eb.executeFunction("sendNonCouncilData",FullContent,true);

The function runs but the html element shows itself and TinyMCE doesn't reapply to the textarea.

The document ready doesn't get fired again but how can I call the hide / apply TinyMCE again?

I think I've gone slightly brain dead.

Thanks

[Jon]

if you add return false; at the end of your button click javascript, it won't call the server and you shouldn't need to re-hide your TinyMCE control.

But generally, it's much better to put page initialisation type Javascript on the ready event of a control (say the panel control containing the TinyMCE), than using document.ready. The document.ready code executes only when the page is loaded, and not when an Ajax refresh occurs, whereas if you put the code on a control ready event, it should work in all circumstances.

[Steve James]

Thanks Jon,
The TinyMCE initiator was on the control but I also needed to hide another control that was on at the page level.

What's the recommendation about messages? In this situation as the function doesn't submit an Ebase error/warning message can't be utilized. A div could be used as a message area, is this the best approach?

The control level html properties reminds me....
It is often tricky to spot when elements have underlying html properties especially when tracing through someone else's form.

It would be good to have some sort of simple highlight on the outline view if the element has additional html properties.

Thanks

[Jon]

What's the recommendation about messages? In this situation as the function doesn't submit an Ebase error/warning message can't be utilized. A div could be used as a message area, is this the best approach?

Not sure I understand this. You should be able to add an error/warning message so long as the executeFunction call has the autorefresh option set to true so the page can be updated with the message. If you do your own thing e.g. with divs, you will need to sort out removing the messages.

It would be good to have some sort of simple highlight on the outline view if the element has additional html properties.

Have you tried the Client Event Map? In V5 you select this from the View menu. It shows all the client side configuration for a form and you can use it to navigate.

[Steve James]

Thanks Jon, I told you I was going brain dead.

This wasn't working for the TinyMCE wysiywg editor. I have to reinitialise it via something like

Code: Select all

$eb.executeFunction("sendStuff",FullContent,true);
tinymce.remove();
tinymce.init();

As for Client Event Map in v5, I had a look on our v5 sandpit environment. That looks good.

We've not taken the plunge of upgrading from 4.5 yet. It's going to be a big job. Do you know how many customers have upgraded in their production environments?

[Jon]

Do you know how many customers have upgraded in their production environments?

We don't have that information. I would guess a few based on questions to this forum.

P.S. Client Event Map is also available in V4 though I can't remember how you access it. Look around the menu options and you should find it.

[Steve James]

Client Event Map in v4, thanks found it, it makes for a very cluttered screen but will be of some use.

v5 investigations started in earnest now.

[dvanhussel]

As for Client Event Map in v5, I had a look on our v5 sandpit environment. That looks good.

We've not taken the plunge of upgrading from 4.5 yet. It's going to be a big job. Do you know how many customers have upgraded in their production environments?

Hi Steve,

We are running production with v5 on one server, but this was not an upgrade. This server has been running just fine since early december 2015.

We are in the middle of updating and testing one of our production servers (on a local copy) It is indeed not trivial, but the results are looking quite positive. And after having done my latest project in v5, makes me want to invest the time even more. I think it is really worth it!

Working with Ebase now matches a lot more with the workflow we use for other development (i.e. Oracle SOA suite BPEL, Java, etc.).

Regards,

David

[Steve James]

Thanks David, I've got a copy of our development environment up and running on 5.0.1 today. I've been looking at v5 from a sandbox perspective for a while, now for the hard work in the real world

We've loads of internal issues that we need to get over.

- designers connecting direct to databases
- hard coded ufs in scripts
- \tomcat\webapps\ufs\ourfolder\...... (syncing between each developer/environment)
- cross domain issues when the client loads the integrated server on localhost
- Windows userid in Ebase in the integrated server (we went for a different approach but have wanted to use the Ebase way for some time)
- others I've not found yet.

If we were to start from scratch today we'd do many things differently but our current setup is the result of goings from way back before Ebase 3.4. I've only just got all our form writers onto JS in preference to FPL.

I'm just in the process of establishing which issues need fixing and which we work around until there is a reason to fix eg hard coded ufs should never have happened but there is no urgent need to fix until we need to work on specific forms/scripts (or use the server side development).

Overall I'm happy that the benefits of v5 out weigh the negatives/issues but I think it may be a bit of a slog to get v5 up and running across our environments.

Thanks for the feedback...