Custom layouts

[pjdodd]

Hello.

Is it possible to allow the user of a standalone Filemaker solution to create and modify layouts (for printing) while restricting their access in layout mode? Also, can scriptmaker be used in layout mode at all?

My idea is to provide a layout screen where say there is a custom panel for the creation of the allowed fields (the status area will always be hidden). The user can move and resize these fields to all them to create a truly custom layout.

[Ender]

No, layout access cannot be scripted. You can control whether a privilege set has edit access to specific layouts, but you can't restrict what they can do while in layout mode.

[pjdodd]

That's what i was afraid of.

Thanks.

[T-Square]

My experience is that most clients would rather have an existing report that they can tweak, rather than create from scratch. This is especially so given the fact that a report usually combines a specific set of fields (view) with a specific order of records (sort), which usually needs to be scripted in FM. Most users don't want to go into that level of detail. So, my approach has been to query the client and try and give them as many of the reports as you can.

That said, I have used a multifile modification of the separation model that uses a separate file specifically for reports, called (miraculously) REPORTS. This reports file is completely open to the client, and they are able to modify the reports as they see fit. I provide the basic reports for the system along with scripts that sort and select the data. If my clients want to change the font or add a field to an existing report, they can; if they want to figure out how to write a script to select and sort the right data and then generate the report, they can do that as well.

If you allow client modifications of your distributed app, be sure your client knows that the changes they make may not get copied to any new versions you create. I had an experience recently where a client changed the reports, then loaded a new version of the software and wondered where their mods were.

HTH,

David

[pjdodd]

My solution is aimed at the print industry where there are many different ways of working and consequently the level of manipulation required for reports and estimates varies to such a degree that it is frankly easier to provide very few basic layouts to clients and say "Here you go....go forth and modify".

But what I'm ideally hoping to do is provide an easy method of creating a custom layout, while still maintaining a tight level of security AND avoiding showing and using the status area and its field dragging onto layout method AND keeping open the ability to use scripts. (Take a deep breath now!)

Having the modifications limited to a separate file means that upgrades are better for the client but I swore I wouldn't go down the road of having the solution cluttered with files. Also, how exactly would that work? I mean would you distribute two standalone applications, one for the layouts bit and the other for the main database?

I guess im trying to have my cake and eat it.

[T-Square]

I hate to say it, but Filemaker IS the method of creating a custom layout...

If you look in the Separation Model forum, you'll see discussions of how to make it work. Generally speaking, with the separation model, you have a data file and an interface file. The data file has all the real data (that the client creates); the layouts and scripts all live in the interface file. The interface file has no data in it, but has a link to the data file and shows data from that file.

With the extension I am using, I have a third, reports, file. It is very similar to the interface file except it has the layouts used for reports and scripts to select the data and sort it.

I'm not sure whether you consider 3 files "cluttered," but it's a far cry from the days before 7...

HTH,

David

[pjdodd]

I've looked into the Separation Model and it's frankly a horrible idea that solves current problems by creating new nasty ones.

I suppose I am looking to separate the interface from the data, in a manner of speaking, by wanting the client to create a layout but not touch the data in any way. Also i really don't like the complication (and speed issues) in having a linked file being accessed.

Anyway I'm using a one file solution that has been developed too much to split now, even if I was insane to do that. Lastly, I though the point about Filemaker 7 was that multiple files were going to be a thing of the past (thank God).

[Inky Phil]

Hi PJ,

I am also developing a solution for the printing industry and understand your problem re:the diversity of what everyone wants.

The general approach to this seems to have been to give the user a choice of about a dozen of the most popular layouts that everyone else uses in an attempt to cover most bases.

If the user really cannot find the format that they can use within those choices then custom layouts are offered to them either at an extra charge or FOC under the monthly licence fee that most software houses seem to charge.

After 35 years in the print industry I have a fairly good idea of the average IQ of the people involved. Whilst we are a quite creative and resourceful bunch I am not yet aware of anybody who has left to become a rocket scientist. I think that to let any of us loose on your solution could be a recipe for disaster.

My approach is quite the opposite to yours. I am spending a lot of time designing layouts that I hope the industry will accept as well thought out to the point that they are an improvement on what they have already. If only it were that simple.....

Whatever, keep smiling and Good luck to you, however you go about it !!

regards

Phil

[T-Square]

PJ--

I don't agree with you that separating the data from the interface is a "horrible idea."

Separating the data from the interface frees up the developer to work on making an interface that can be distributed to different end users without requiring the developer to modify or handle the various clients' data--either directly, by having clients send in their files, or indirectly, by writing scripts to migrate data into upgrades.

I think it also improves the security of the solution, as it is possible to lock down the interface while allowing the clients to have full control over their own data. And if I don't have to handle their data, it's that much more stable for them.

You speak of speed issues in the SM, but I haven't seen any such problems in my own experience, nor have I heard of any from my clients. Their speed complaints usually crop up because of some routine that I have written poorly.

Your comment that the SM creates "new nasty" problems, is something I'd like you to expand on; if you've seen some nasty problem, I'd like to know because maybe I've missed something big. I'd sure like to find that out before I get burned! Moreover, perhaps the collective wisdom of the Forums could look at the problems you've found and offer fixes for them.

Speaking from my own experience, I am a lot less insane since I adopted the SM. I can fix a problem in the interface and send it out to my clients the next day, without disruption to my clients' workflow. As acknowledged in other threads, changes to the data structure are more difficult--as difficult as interface changes used to be.

Transitioning to the SM in your situation would (I suspect) in fact be simple, since your solution is in one file; I found that the trouble in transitioning to the SM cropped up because of all the ugly workarounds I had to cobble together in the 15-file FM6 app I had.

Finally, you comment that FM7 makes multiple files a thing of the past. However, what FM7 does is free up the developer to decide WHEN the use of multiple files is appropriate. Others have pointed out that a solution might appropriately use multiple files--for example, if it were modular, or if one table were expected to grow disproportionately relative to others.

The SM is simply a design technique that can be applied, and maybe it's not appropriate in your situation, just as blue jeans are probably not appropriate at a black tie affair.

David

[pjdodd]

Hello Inky Phil

Regarding the print industry - to quote my first boss "Always think of them as the one brain cell club".

I had hoped to avoid presenting a myriad of layouts as this would put myself in the position of being psychic trying to ascertain the largest possible variations without bloating the size of the database and actually spending little time on layouts. I entirely agree that to let them loose on a database is a very bad idea. But then with say 20 layouts to choose for your printed Estimates alone, how do you present the choices in a way that remains simple and clear? At the moment I've limited the layouts to only 3 as i'm focusing on getting the functions right.

The problem with the print industry methods of working is that many are crass adapations of complicated procedures – using effing Microsoft products - most printers near me use Excel for Estimating for Gods sake! To make matters worse, every printer has undertaken there own adapation, resulting in each printer working slightly differently.

Obviously solutions shouldn't be adapted to fit inaccurate spreadsheeting methods. But then should they, given that printers actually use them? How do you convince them that their current method in inferior to your developed one? With FM7 ive been able to restore the traditional methods of estimating but significantly updated so the user is led thru screens with clear input. It's a lot more accurate than using a ******* spreadsheet!

The plan for a demo to be released in Jan 2006 is still going ahead. Then it's wait and see.

[pjdodd]

Hello T-Square

With regards to speed issues: when the data is static I agree it's hunky dory. When the data is a lot of variables and calcualtions then it starts to drag, significantly. As a single file this is still the case but as referenced files it's really bad. My solution is a web of relationships that's the equivalent of 7 may be 8 separate files. I take your point about blue jeans not at a black tie dinner. For my solution, it's all in one.

The nasty problems it creates are (and these are based on my scan of the SM forum and my own limited experience)

1) The required links for certain relationships to work. (see the SM forum for this, the post i read scared me).

2) Tracking versions: more files, means more coding for tracking which versions, and then deciding whether v3 data works only for v5+ interface file. Nightmare. One file. No problem.

3) Separating the data from the interface ignores the fact that improvements to the functionality of a database will EVENTUALLY lead to an alteration in the data structure (ie adding fields, changing validation in others, adding links and self links etc). Shifting those changes onto the interface file delays the inevitable and not only postpones the major headache of a data structure upgrade but actually makes it slightly worse by delaying it. Splitting the data doesn't solve the problem of a fussy client!

4) Security. Who cares about the interface - if someone got the interface file, locked or unlocked, big deal. If they got the data files I'd panic. That's the crucial point about security is it not - to keep the data away from prying eyes. All in one solution with controlled access and it's all safe.

As i'm looking for a method of providing the user to create their own layouts (while restricting their access and damage they can inflict in layout mode) I can see the lovely vision offered from the SM model. The path to it is treacherous and not worth it for my solution - blue jeans not suitable here.

[Inky Phil]

Best of luck with the demo launch PJ

Let me know how you get on with it

Phil