Page Transformation Tool

rdebath

No not that.

It strikes me that if Microsoft are to be believed we should be writing new code as Pages not Forms. That makes the current Transformation tool wrong. The concept is right, "only write the code once" but it's the wrong way round.

Does anyone know of an available a 'right way round' tool that takes Pages and converts them into Forms? It should be easier to write, after all a Form can do anything a Page can do and more; Matrix Page anyone?

kine

For me the access is correct.

1) Everybody have FORMS already, and need to create Pages for them
2) Pages are much stronger than forms (you can do on page what you cannot in form), thus transforming Form to Page is easier, because in most cases the form is subset of page functionality

If you will read Statement of Directions, you will see the next step in NAV, which will solve this for you... ;-)

rdebath

kine wrote:

If you will read Statement of Directions, you will see the next step in NAV, which will solve this for you... ;-)

Well, yes. That's the problem, I read it just before I posted and I don't really fancy being shoved into the deep end but right now I have two choices...

• Write everything twice, waste time and money.
• Use the existing tool, program with Forms and basically ignore pages. Maybe they're better in the long run but I will only see the problems and the irritations (like the inability to do matrix forms or the limited list of 'page types' or the fact you can only put one subpage on a page or the fact you can't call functions on factboxes from the main page... the list goes on ... events, timers ...)

In fact I've only seen one advantage to using Pages, customers think they look nice. Even the addin functionality has severe limitations (Only visual controls, user can kill even essential controls) and irritations. (Not programmed in NAV).

kine

That's problem of each radical change of technology... where old things are not supported anymore. But everyone is solving it somehow.

Transformation tool have one pro: if you set it once to work, it will work nearly automatically and you adjust only the new things inside. It means, there is one big job to set it up and than it works. Of course, if you have heavilly modified forms, which are not following NAV GUI guidelines, it could be very difficult to transform the forms. But who's fault it is?

rdebath

Actually, I think most people are doing the normal thing of ignoring it till it bites them. Me to, but being a bit of a neophile I have been looking at it, which is why I have setup the Form transformer, I have got working and non-working three-tier setups. And can see a big lump of work coming my that I want to reduce or at least spread out. Hence the request for a Page Transformation Tool.

NAV GUI guidelines ... But who's fault it is?

Usually the customer's, they always run fullscreen and see this huge space to the right that they want a factbox or four in, after all it "only a guide, not like it's a rule or anything".

Anyway, the Form Transform tool is a lot more restrictive than the GUI guidelines, though I'll admit it has been a while since I looked at them, just look at all the standard forms that are set to ignore; they're not all matrix forms.

Not that that's important; I'm talking about new forms/pages right now.

Oh well, it looks like I'm in the setup of an "I told you so".
We'll probably just end up ignoring the training problem, keep writing forms and all the developers will hate pages because they only ever see the broken ones.

BUT, meanwhile I'd like some ammo...

2) Pages are much stronger than forms (you can do on page what you cannot in form)

Do you have some specific (ie: page is obviously better) examples?

kine

Usually the customer's...

For customer's fault is responsible the partner... ;-)

Do you have some specific (ie: page is obviously better) examples?

E.g. like two subforms connected between each other (without code)?

rdebath

kine wrote:

Usually the customer's...

For customer's fault is responsible the partner... ;-)

Okay, Okay, but we do want to, you know, not piss off the customers and make some money.

kine wrote:

Do you have some specific (ie: page is obviously better) examples?

E.g. like two subforms connected between each other (without code)?

Sorry, I think that's the wrong audience. The ProviderID is probably an okay example for consultants but developers aren't scared of code and a millisecond timer + 'dirty bit flags' is easy enough to follow.

kine

Okay, Okay, but we do want to, you know, not piss off the customers and make some money.

That's in most cases the mistake and source future problems. Now the customer is not pissed off, but in future, he will be, because the raising cost of support and updates. You need to focus on long term satisfied customer, who trust you if you tell him that something is not good and there is another, better, solution. But this is for another discussion and I think that David Singleton will have more to write about this... ;-)


In general, pages are more flexible, of course, because it is "first version", there are some missing features when comparing with Forms, but e.g. possibility of customizations is un-comparable with the forms. Of course, the pros will be stronger with each new version and I cannot imagine such a grow with the forms.

rdebath

but in future, he will be [pissed off]

I think I agree with you, probably 99.9% of the forms in the system will be 'wizard forms' but for best relations there will almost certainly be one or two heavily customised forms. The customer will know they are difficult and expensive to modify but it's worthwhile to the business because in effect they are the 'Role centres' of V3 Navision.

because it is "first version",

If you go by normal Microsoft bug and feature counts this being a SP1 product is probably feature complete with the majority of remaining bugs in places that can be worked around.

And looking at what I've seen of pages I can't see many avenues for flexibility and customisation. In fact the only way I see to do something novel is to dump the NAV page control and use a c# AddIn.

I don't really mean the petty limitations like the old charts can only be green, or controls can only be read and green. I'm more looking at the deep seated things like this 'pagetype' property; flexible GUI design is one of the places where 'duck typing' seems to work very well (looks like, quacks like -> must be a.) and this property is the antithesis of duck typing. It's like saying that this HTML page can only appear in the top right of a frameset, perhaps a useful limitation at first but it immediately stops you adding a far right column to the frameset.

Even something as simple as a 'Status board' showing KPI values on a big screen, updated every minute needs a C# addin for the timer.

In general, pages are more flexible ... e.g. possibility of customizations is un-comparable with the forms

Please show me; all I see at the moment is reductions in flexibility. Turning the GUI guidelines into inflexible, zero tolerance, walls of denial. With obvious symptoms like the allowed colours for text.

kine

All is question of angle of view. If you need big screen page with KPIs, why you are using RTC? Just use e.g. Sharepoint (the new KPIs things in Sharepoint 2010 could help you in this... ;-).

Second - design of pages is "display target independent". All "limitations" you feel are in most cases because that. But with more possible targets you will gain (SharePoint Target when available, mobile target etc.). When you need some specific request, you have different tools to fulfill it (addin, webservices etc.) - yes, it means developing outside NAV (VisualStudio etc.), but NAV is for rapid business application customization...

NAV 2009 needs change of our behavior, change of way of thinking about NAV and used patterns to solve things. There are different ways how to solve it. And yes, there are tendencies to "push" other products which are solving the specific things and are focused to selected area. NAV partner focusing only on NAV will have these problems. If you want to sell and support NAV, you need to know about SQL, Sharepoint, SSRS, WebServices, VisualStudio etc. You need to be able to connect these products together, how to use them, when to use which etc. Yes, of course, there is higher "cost" for customer, but when done correctly, this cost is not so high from long term view.

Just to make it clear: I do not want to tell you, that there are simple solutions for everything, and yes, there are missing features in NAV 2009 (SP1 is only correcting some main problems), but still, take it as a new product, because it is a new products. That inside it is working on nearly same business logic is just "side-effect" and way how to support existing customers and partners. Yes, there are situations, which could be solved in classic client easily, but are un-solvable by RTC tools. But you need to start thinking out of the box to solve it.

Each time I am saying to customer:"everything could be solved. It is only a question of given budget, resources and time...". And yes, sometime you need bigger budget, sometime smaller and everybody is now learning how to do all this with NAV 2009... 8)

rdebath

I was going to deal with your points one by one but I'm not one for taking positions that look like a fanatic's stand.

I think I'll just make the point that if Microsoft can be seen to have a monopoly position it looks like they'll be back in court for abusing it again.

AND this is really NOT helping me to convince anyone that the RTC is a good idea!