What about form triggers with 5 Version

ajaybabuCh

Hi


Does Navision 5 version support all the form triggers as we have some business logic in form triggers in present and previous versions.

regards
ajay

ara3n

5.0 will support it but 5.1, I don't know. MS has recommened to move the code to Codeunts.

I've always recomment to write your code at the table triggers. So it's still early to move your code to tables and codeunits.

Administrator

[Topic moved from Navision to Upcoming version 5.0 (AKA Dynamics NAV) forum]

ajaybabuCh

If version 5 doesn't support all the triggers of navision present version
What about the addons that already developed and the customizations
for the customers having some business logic in the forms

ara3n

well with any addons and new versions you have to change the code to work with new version.

Waldo

First of all, that's what the beta program is for ... to be assisted in upgrading the ISV solution.

Furthermore, it seems logical to me that there will be form triggers for design reasons (conditional formatting,...). For now, you can make sure to minimize the amount of code you write behind forms.

ajaybabuCh

can give me some idea on what is Beta programming

Waldo

ajaybabuCh wrote:

can give me some idea on what is Beta programming

:-k

For us it means:
- Having an ISV solution that will be upgraded with the assistence of Microsoft;
- Having training by Microsoft;
- Being prepared for the launch;
- Having a client that gets attention in the Media

David_Singleton

ajaybabuCh wrote:

If version 5 doesn't support all the triggers of navision present version
What about the addons that already developed and the customizations
for the customers having some business logic in the forms

Since the release of the Windows version of Navision, they have been pounding into developers that coding on Forms should only be used for formating data, and should never be used to modify the database. (Yes I know even their own programmers have not listened some time).

If you have code in forms that should not be there, now is the time ot start restructuring and making it work the right way. If we were to have code on forms that triggers database changes, then what would be the purpose of a thin client. In my opinion, the thin client is a presentation tool, and thats all. All processing should happen on the business logic server.

Mbad

You can still code on forms in 5.0

Miklos_Hollender

But what IS the purpose of having a thin client anyway? Did anybody ask for it? An alternative thin client for those who are obsessed by keying in orders in netcafes might be occiasionally nice but it shouldn't be considered a paradigm change.

This whole thin-thing is nothing but the MVC concept (Model-View-Controller separation). And this is a useful thing for some purposes - especially in those cases long-term maintenance is important - but not for all cases, it's clearly not a one-size-fits-all solution. Rich clients, strongly interconnected, non-layered business logic and presentation has it's uses (think of PHP), mainly when you need to do quick-and-dirty things, or rapid prototyping, or when the expected behaviour is not that of a database application, so you have to make it not look and feel like one, or when you want your customizations have a minimum footprint etc. etc.

Miklos_Hollender

In other words, when this MVC concept fails, it fails because from a developers viewpoint a user interface might be just a "presentation tool" or a "layer", but from the user's viewpoint, that's the WHOLE application itself!

DenSter

:shock: I'm surprised by this question...

It's not so much the thin client bit that is most important, it's taking the business logic away from the clients onto scalable server machines. Cutting down network traffic, speeding up transactions, things like that.

David_Singleton

DenSter wrote:

:shock: I'm surprised by this question...

It's not so much the thin client bit that is most important, it's taking the business logic away from the clients onto scalable server machines. Cutting down network traffic, speeding up transactions, things like that.

=D> exactly.

And putting business logic on the presentation layer ruins this.

Waldo

Mbad wrote:

You can still code on forms in 5.0

Yes, OK, I think so too.

But will you write business logic here ... I think not.
Will you be able to access the database by code ... I think it shouldn't be possible.
For having the client as thin as possible, we should not have business logic on forms.

I still do have one question with that. Will NAV still have huge code after the OnValidate-trigger (probably it will) ... so after validation, we're going to have quite a lot network traffic after all ... making the client not as thin as we want it to be ... . This is something I wonder what the answer of MS will be. :-k

kriki

Waldo wrote:

Mbad wrote:

You can still code on forms in 5.0

Yes, OK, I think so too.

But will you write business logic here ... I think not.
Will you be able to access the database by code ... I think it shouldn't be possible.
For having the client as thin as possible, we should not have business logic on forms.

I still do have one question with that. Will NAV still have huge code after the OnValidate-trigger (probably it will) ... so after validation, we're going to have quite a lot network traffic after all ... making the client not as thin as we want it to be ... . This is something I wonder what the answer of MS will be. :-k

I think there will be less network traffic. Because the OnValidate (on the first layer) sends a message to the 2nd layer and accesses the DB (3rd layer) but 2nd and 3rd layer are close, so no problem.
I have more doubts about speed over the internet.
The first layer will have to wait a lot before the response comes of the 2nd layer after running the onvalidate-trigger.

DenSter

If the presentation layer were only to be used for display purposes, I would be surprised if we still had a Validate trigger on the form.

Waldo

Well,

I guess the field still has to be validated. The validation itself will be done by service tier, but the call-to-validate needs to be done. This doesn't need to be a heavy call over the internet ... but it has te be done. If this generates much trafic over the network is a question where only Microsoft has the answer for at the moment.

David_Singleton

DenSter wrote:

If the presentation layer were only to be used for display purposes, I would be surprised if we still had a Validate trigger on the form.

Or to take it a level further, IF we have a validate trigger at the form level, then what would be the purpose of the thin layer.

All processing commands should be sent back to the 2nd layer, and processed there. The Client layer should be thought of more as an "intelligent Navision customized Citrix type client.

DenSter

Waldo wrote:

... but it has te be done.

I see your point.... I don't know.... maybe some kind of postback to the service tier? Maybe that's the reason it's on IIS. :-k

Waldo

DenSter wrote:

Waldo wrote:

... but it has te be done.

I see your point.... I don't know.... maybe some kind of postback to the service tier? Maybe that's the reason it's on IIS. :-k

I really am anxious to know the answer ](*,)

Miklos_Hollender

Sorry, but I think it all is just just wishful thinking. I think the most important rule of not only ERP, but IT in general is to prepare for the worst possible case. Like, prepare for the case when it turns out that you grossly misunderstood requirements, you are three days before go-live, you have to make huge changes in no time and for free and the company owner is an ex-KGB mafia boss meaningfully playing with a machine gun. Not that it would happen frequently but you must leave the option open to manage such cases. "Shit happens" is the typical characteristic of IT in general. Granted, most of the time you are more interested in long-time maintanability, network load, interchangeable presentation options (client, web, report, Excel) et cetera, et cetera - but taking away the option to be as quick as possible at those times when it does not really count how dirty it is is clearly suicidal.

Miklos_Hollender

In classical Model - View - Controller (3-tier, if you prefer this term) systems forms (the View) only do basic validation like data type, field length, regex-matches (f.e. a phone number format) and so on. Sometimes, a field can validate based upon a value of another field on the same form, like in MS CRM. But in those systems table relations etc. are generally not checked until the form is saved/posted/OK-d. This is one of the reasons why MVC tends to be quite clumsy for many applications.

Basically, in the long run, if Navision embraces the MVC paradigm it will mean that it will be reduced to the role of a truly and ERP/CRM/whatever system, meaning that it will be used only for the original sense business software are usually used: entering data, largely based on table relations / foreign keys and practically nothing else. Meaning that all those current "not really ERP" applications like f.e. product configurators will have to be moved outside, to C# programs. Which will mean that Navision will move upwards on the market, to the higher end of the medium business market, for those companies who do have an IT strategy, are interested in platform/architecture questions, and are able to pay the costs of it, and it will be less feasible to implement at small ones. Probably it also means more focus for add-ons and less focus for customizations which I consider suicidal but we'll see. The interesting thing is that because as SAP B1 turned out to be an utter horrible crap, there is basically nothing popular out there for the low end of the market and will be even less when NAV 5.1 is out. Because even the cost increase just due to the more complicated installation of the server - probably alongside with Reporting Services - will repel smaller companies by itself, not counting the other costs.

wwestendorp

I've heard from Microsoft that it will b epossible to use code in forms since it will be Pages which will be made from codes + forms.


I don't know which triggers will be in the Forms (eventually the pages)


Merry X/mas t y'll! :shock:

MTC

Are there any official specification/policy/best practice documents on this matter? If so, does anyone have a link?

Waldo

No there isn't.
All we have is an "Airlift" of 5.0, but no technical preview of 5.1.

Patience is a virtue

kriki

Waldo wrote:

Patience is a virtue

Patience is a virtue one admires in the driver of the car behind us and hates in the driver of the car before us.

BTW : it is not out of topic, because the saying serves for awaiting the 5.1

PerJuhl

Miklos Hollender wrote:

In classical Model - View - Controller (3-tier, if you prefer this term) systems forms (the View) only do basic validation like data type, field length, regex-matches (f.e. a phone number format) and so on. Sometimes, a field can validate based upon a value of another field on the same form, like in MS CRM. But in those systems table relations etc. are generally not checked until the form is saved/posted/OK-d. This is one of the reasons why MVC tends to be quite clumsy for many applications.

Basically, in the long run, if Navision embraces the MVC paradigm it will mean that it will be reduced to the role of a truly and ERP/CRM/whatever system, meaning that it will be used only for the original sense business software are usually used: entering data, largely based on table relations / foreign keys and practically nothing else. Meaning that all those current "not really ERP" applications like f.e. product configurators will have to be moved outside, to C# programs. Which will mean that Navision will move upwards on the market, to the higher end of the medium business market, for those companies who do have an IT strategy, are interested in platform/architecture questions, and are able to pay the costs of it, and it will be less feasible to implement at small ones. Probably it also means more focus for add-ons and less focus for customizations which I consider suicidal but we'll see. The interesting thing is that because as SAP B1 turned out to be an utter horrible crap, there is basically nothing popular out there for the low end of the market and will be even less when NAV 5.1 is out. Because even the cost increase just due to the more complicated installation of the server - probably alongside with Reporting Services - will repel smaller companies by itself, not counting the other costs.

Hi

Good point, you got there.

It all seems a "bit" driven by the technology.

Hope we can find enough customers with enough money.

What is the main strength of "Old style Navision" ?

If the strength of "Old style Navision" is gone with 6.0, will it
still sell as good as today ?

90% of Navision customers give a dam if it's 3 tier or 2 tier.

3 tier will only sell at the right price.

BR Per