John

All users do not need to live with the constraints that IWP imposes. However, 
if you give FMP users functionality that is not available to IWP, then indeed 
you need some strategy to separate the two users. One way to do that would be 
simply to branch scripts appropriately, as you suggest.

However, it is probably more efficient and easier to program if you completely 
separate the two functionalities. You can have IWP users access completely 
different layouts (designed to be more appropriate for web users). Buttons on 
those layouts can be linked to completely independent scripts that provide the 
more limited functionality. You can name your layouts and scripts appropriately 
– using say a "iwp-" prefix for layout and script names associated with IWP.

The underlying tables (and therefore data) are the same, but the whole user 
interface is separate. That seems to be what you are after when you talk about 
'two linked versions'.

If this is still not enough, you could always put all the IWP functionality in 
a completely separate file. You place table occurrences in the relationship 
graph from your 'main' (ie FMP) file, thus ensuring that the same data is used.

You may have read about the 'separation' model of Filemaker development, where 
there is one file containing all the data tables (but no or minimal scripts and 
layouts) and another containing all the interface elements such as layouts and 
scripts? I have used that on at least one occasion with multiple interface 
tables: one for regular FMP, another for FMGo, and another for IWP. This makes 
it much easier to manage these multiple methods of accessing the data. The 
disadvantage though is that sometimes a function has to be written or modified 
in three different versions. Still, since FMGo and IWP are so different from 
FMP, a similar amount of work might be required even if they all used the same 
file.

Does that help at all?

Steve

On 7 Sep 2011, at 14:40, John Eiseman wrote:

> Having informed my client that IWP precludes the use of some script steps and 
> some strategies, he responded that he would like me to develop two versions 
> of their solution; one for access via IWP and the other for in their office 
> via Server access ... yet have the two linked, accessing the same data.  Most 
> of their users are in the office. The client doesn't want me to 'dumb-down' 
> his solution just so that a couple of remote users can access via IWP.
> 
> Rather than have two linked files, I suppose I could have just one solution 
> and every time I reach a point where I'd like to use a non-web script step I 
> test the user, and if he's accessing via IWP, then I execute one set of 
> steps, and if he's not, I use a separate set.  But it seems that this would 
> be very inconvenient to program.
> 
> I'm basically an amateur and don't know if two linked versions is possible, 
> at least not easily.  Therefore, I'm hoping that there's a better way of 
> accomplishing what the client wants that I'm unaware of.
> 
> If a client needs some users to access via IWP, must all users live with the 
> constraints that IWP imposes?
> 
> Thanks for any advice you can give me.
> 
> John Eiseman
> St. Louis

Reply via email to