To Portal or not to Portal 
Author Message
 To Portal or not to Portal

FM 5.5 Dev/Mac OS 9.2.2

I have a question that looks like it relates more to design philosophy
than to a specific problem.

I'm building a purchase order/receiving solution.  The data is currently
being imported from the old DOS software that my new solution will
partially replace.  I have two files: a PO Headers file with basic data
(vendor ID, dates, PO number, terms, etc.) and a PO Details file that
contains the line items associated with the PO Headers.

Everything is set up correctly, as far as I know.  I'm now beginning to
make layouts to print various reports & allow user interaction.  In my
initial hack at it, I made a layout in the PO Headers file that contains a
big portal that fills with that header's line items.  I put a bunch of
scripted buttons in the header layout part to do various things, and it
all works so far.  Some of these PO's can be huge, so I had to make my
portal cover about six pages, causing some odd effects when printing a
multi-page report.  But I've jiggered these into place.

Over in the PO Details file, I've made a layout to do other stuff, and
this time I don't need a portal, just a list layout.  There is one
irritation in that I have a couple of global fields for user data entry,
so scripts can scoop them up & do stuff with them.  Apparently, you cannot
put a global field in the header part of a list layout, though you can
with a standard layout.  This means I have to put the globals in the
actual line of the list, making them appear to show up on every line of a
long list.  It looks weird, confuses non-FM experienced users, and takes
up valuable horizontal real estate that could be used for displaying more
fields.

Aside from that global problem (which may be resolvable by going to a
self-join portal in the PO Details file instead of a list layout), I'm
beginning to lean on making all the user layouts live in the PO Detail
file, instead of some in the header file & others in detail, causing the
user to have to go to different files to do different things.

Is there an advantage or disadvantage I'm not seeing to placing all user
activity in either the header file with lots of portals (one advantage:
it's a much smaller file than details) or the detail file with lots of
list layouts?

It looks like I can go either way and I need to commit one way or another
pretty quickly.  Performance will probably not be an issue as the files
are fairly small.  PO Headers will always have roughly 1,700 records,
while PO Details will have about 35,000 line item records.

Any advice, or pointers to where this sort of thing has been written
about, is much appreciated.

Steve Brown



Thu, 20 Jan 2005 01:04:35 GMT
 To Portal or not to Portal

Both. Print and preview from the line items file; perform data entry from
the PO file. Perform searches in the line items file, but call them from the
PO file.

You shouldn't need to expand your portal to 6 pages; rather, use a scroll
bar and show the first 20 items or so. In the line items file, create PO
forms for printing and preview, and create appropriate scripts for printing
and previewing. Then call these scripts from the PO file, preceeded by a
GTRR. The GTRR ('Go to related records[Show only related records]') will
create a found set in the child file of just the line items for that PO.

Store the aggregate values for the PO (total price, tax, S & H) in the PO
file, but place the extended price per item in the line items.

The main page of a PO form is unlikely to need any parts other than the
body, so long as it is confined to 1 page.

--
John Weinshel
Datagrace
Vashon Island, WA
(206) 463-1634
Associate Member, Filemaker Solutions Alliance


Quote:
> FM 5.5 Dev/Mac OS 9.2.2

> I have a question that looks like it relates more to design philosophy
> than to a specific problem.

> I'm building a purchase order/receiving solution.  The data is currently
> being imported from the old DOS software that my new solution will
> partially replace.  I have two files: a PO Headers file with basic data
> (vendor ID, dates, PO number, terms, etc.) and a PO Details file that
> contains the line items associated with the PO Headers.

> Everything is set up correctly, as far as I know.  I'm now beginning to
> make layouts to print various reports & allow user interaction.  In my
> initial hack at it, I made a layout in the PO Headers file that contains a
> big portal that fills with that header's line items.  I put a bunch of
> scripted buttons in the header layout part to do various things, and it
> all works so far.  Some of these PO's can be huge, so I had to make my
> portal cover about six pages, causing some odd effects when printing a
> multi-page report.  But I've jiggered these into place.

> Over in the PO Details file, I've made a layout to do other stuff, and
> this time I don't need a portal, just a list layout.  There is one
> irritation in that I have a couple of global fields for user data entry,
> so scripts can scoop them up & do stuff with them.  Apparently, you cannot
> put a global field in the header part of a list layout, though you can
> with a standard layout.  This means I have to put the globals in the
> actual line of the list, making them appear to show up on every line of a
> long list.  It looks weird, confuses non-FM experienced users, and takes
> up valuable horizontal real estate that could be used for displaying more
> fields.

> Aside from that global problem (which may be resolvable by going to a
> self-join portal in the PO Details file instead of a list layout), I'm
> beginning to lean on making all the user layouts live in the PO Detail
> file, instead of some in the header file & others in detail, causing the
> user to have to go to different files to do different things.

> Is there an advantage or disadvantage I'm not seeing to placing all user
> activity in either the header file with lots of portals (one advantage:
> it's a much smaller file than details) or the detail file with lots of
> list layouts?

> It looks like I can go either way and I need to commit one way or another
> pretty quickly.  Performance will probably not be an issue as the files
> are fairly small.  PO Headers will always have roughly 1,700 records,
> while PO Details will have about 35,000 line item records.

> Any advice, or pointers to where this sort of thing has been written
> about, is much appreciated.

> Steve Brown



Thu, 20 Jan 2005 01:45:00 GMT
 To Portal or not to Portal

Quote:

> In my
> initial hack at it, I made a layout in the PO Headers file that contains a
> big portal that fills with that header's line items.  I put a bunch of
> scripted buttons in the header layout part to do various things, and it
> all works so far.  Some of these PO's can be huge, so I had to make my
> portal cover about six pages, causing some odd effects when printing a
> multi-page report.  But I've jiggered these into place.

"Jiggering" in this case is not really the best approach. For printing
POs, pick lists, receiving sheets, or any other set of records in a
child file, print FROM the child file. Bring in related header data
through relationships.  Then there is no need for six page portals and
sliding which does not really work well, as you've discovered. Portals
are not meant to print, and that's why they don't function well in
printing.

Quote:

> Over in the PO Details file, I've made a layout to do other stuff, and
> this time I don't need a portal, just a list layout.  There is one
> irritation in that I have a couple of global fields for user data entry,
> so scripts can scoop them up & do stuff with them.

Why not put the globals back in the header file, to be filled in before
printing? Understand, the PO can be VIEWED in the header file, using the
portal. The users never actually have to SEE the printing layout if they
don't need to. Make the globals for the user choices appear in the
header file.

Then script going to the print layout, sorting, and printing in the
child file, and call it from the parent file.

Quote:

> Aside from that global problem (which may be resolvable by going to a
> self-join portal in the PO Details file instead of a list layout), I'm
> beginning to lean on making all the user layouts live in the PO Detail
> file, instead of some in the header file & others in detail, causing the
> user to have to go to different files to do different things.

Although the script may go to different files, users don't have to see
it. To users, it's like they never left, so who cares?  Well, the
developer cares because it IS more work, but the end result is a more
elegant, nonconfusing interface for the users, and that's the only
worthwhile goal.

Quote:

> Is there an advantage or disadvantage I'm not seeing to placing all user
> activity in either the header file with lots of portals (one advantage:
> it's a much smaller file than details) or the detail file with lots of
> list layouts?

Well, I've always believed that in the end, placing data and
functionality where they most logically belong, rather than trying to
enforce artificial "stay in one file" or "have fewer files" constraints
pays off bigtime. It reduces overhead on maintenance and future
development if you see header info in the header file, and print from
the child file. If you make related records from the parent file (not
the child file).  You need both files in any case for the correct data
structure, why not use them BOTH for the maximum benefit?

Trust me, users pay little attention to WHAT file they're in. Half the
time (or more) they haven't a clue. What they do know is what SCREEN
they're looking at and what they're trying to do there. Give them the
elegant functionality, and they'll entirely forget there's more than one
file.  
--
Lynn Allen              Allen & Allen Semiotics
FSA Associate           Filemaker Consulting & Training



Thu, 20 Jan 2005 02:18:05 GMT
 To Portal or not to Portal
Major thanks to you and John Weinshel.  I combined both your posts into a
text document which I am saving for myself.  I know this is reinventing a
wheel which has been invented many, many times for you guys, and I
appreciate your patience in going over it for what must be the ump{*filter*}th
time.

I am pretty new to FM and this is my first serious project.  FYI, I have
the luxury of not needing to implement everything at once.  My company is
smallish (two dozen work stations, 12,000 inventory items) and is
currently running on an old DOS inventory system.  My goal is to gradually
work my way through the company and rewrite each person's work module into
FM.  I am getting full .csv dumps of the DOS software daily, which I am
importing & exporting into my FM work-in-progress, to keep the data
accurate and current.  Eventually, everything but the general ledger will
be running on FM.  Then we swap that out with a nice Peachtree package,
and the old DOS system will quietly fade into oblivion.

The purchase order module I'm working on "really" needs its companion
purchase order *creation* module.  But I am making this as a receiving
report first, and later I will add the capability to create new P.O.s.  So
I already have the complete P.O. data, with costs & everything.  I'll just
make it all much better later.

With the advice you two have given me, I can now see that when the time
comes to add the capability of creating new P.O.s to what I've done, it'll
be a relatively easy job.  Add a new layout or two & a batch of scripts.

A few brief comments on Lynn's post:


Quote:

>Then there is no need for six page portals and
>sliding which does not really work well, as you've discovered. Portals
>are not meant to print, and that's why they don't function well in
>printing.

This is a major intuitive leap for me.  Somehow I'd gotten the idea that
portals were the way to go to print all manner of reports.  It sure is
easier to simply use a list view layout in the detail file!

Quote:
>Although the script may go to different files, users don't have to see
>it. To users, it's like they never left, so who cares?

This is another intuitive leap.  I've set this up, via "go to related
records", then a "perform subscript" that calls on the external script in
Details.  For now I've left a pause in there, to make sure we have the
right thing before printing, but when I take this out, it will do just
what you said, print right off the Details file without this file ever
appearing onscreen.  Magic!  Hit a button labeled "print" and what comes
out looks completely different than what you see!

thanks again from one happy filemaker,

Steve Brown



Fri, 21 Jan 2005 04:18:08 GMT
 
 [ 4 post ] 

 Relevant Pages 

1. Oracle Portal vs Novell Portal

2. Add item in line item portal from another portal

3. FILTER PORTAL RECORDS - DISABLE ADDING NEW RECORDS IN A PORTAL

4. Copy Portal to Portal

5. Displaying a portal based on a portal

6. Portal for line of data in a portal?

7. Simulate a Portal within a Portal...

8. Portal Within A Portal (Heirarchical Listings)

9. portal within portal?

10. portal in a portal?

11. Goto related from portal --how do I get the selected portal row

12. Conditional portal displays with criteria from another portal


 
Powered by phpBB® Forum Software