David Bandel | 29 Apr 04:26 2007
Picon

xhtml compliance and the menu

Chris and crew,

Been following the discussions on the list while reviewing display
code for xhtml compliance.  Some good discussion.  Waiting to hear
some of these good recommendations turned into direction.

As for the xhtml:  Most changes will be inconsequential (removing
inappropriate outer containers, ensuring attributes are properly
quoted, removing unsupported attributes, etc.).

However, the display code for the menu is a bit more complex and
requires some code changes.  As is, the various menu.pl scripts source
menu.ini and use the bracketed menu values for div_id values.
Unfortunately, many menu values contain spaces and one includes the
ampersand.  Since these characters are not legal in xhtml, and to
maintain display esthetics, I propose adding a "div_id=" value to each
item in menu.ini.  This will, however, require additional coding in
menu.pl to change from div_id="$menu" to div_id="$div_id" as read from
menu.ini and adding that to the getDocumentId routine.

Unless someone has a more elegant solution, I'll start on those
not-so-inconsequential changes as soon as early next week.

Ciao,

David A. Bandel
--

-- 
Focus on the dream, not the competition.
            - Nemesis Air Racing Team motto

(Continue reading)

David Tangye | 29 Apr 11:19 2007
Picon

Re: Redeveloping the system - was Thoughts on payment handling in 1.4.x

On Fri, 2007-04-27 at 19:47 -0700, Chris Travers wrote:
> Actually, I would slightly quibble with this point.  Rather than
> define terms precisely (since natural language is descriptive rather
> than prescriptive), it is a good idea to discuss what we mean by what
> we say and challenge eachother to find better words.  But we see the
> same need for clarity.
Sounds more like you are expanding on what I said, rather than
quibbling.
> If a field in the database is TOASTed, is it still a column?
I do not know what toasted means.
>   What is
> the difference between a field on a report and a column in a tabular
> report?
That's a totally different usage of column from column in a database. A
database column might be viewed or presented as a field in a report.
That field might be laid out in a column, ie its layout or format is
columnar.

> Actually to be most precise, there are neither fields nor columns in
> the database.  Only sets and members of sets.
No sorry, sets, members, tuples etc is the university way of
learning/speaking mathematically about the subject and relational
theory. When an RDBMS is implemented in the industry, eg by Oracle,
Sybase, MySql, IBM and all others I know, except lame Microsoft with
their MSAccess piece of garbage, they all speak of tables, columns and
rows.
> > If no development method (process plus artifacts) is agreed, how is
> > everybody going to work together?
> 
> Areas of expertise, precise communication, etc?  Development of
(Continue reading)

David Tangye | 29 Apr 11:52 2007
Picon

Re: Thoughts on payment handling in 1.4.x

On Sat, 2007-04-28 at 09:40 -0700, Chris Travers wrote: 
> Hi Ed;
> 
> 
> > I can't help wondering if the current Quotes/Order/Invoice model isn't
> > slightly too few states for some business.
> >
> > My model is: [snip]
Its a bit of a problem in a way, that the implied business operational
model and rules is one cast-in-stone set from the mind of one sql-ledger
creator, who has been noted for uttering such sentiments as 'this is how
business should work'. While it does work for a good % of folks, it does
not suit many others. It always occurred to me that a little more
flexibility would be nice in some cases.

BTW: Huge flexibility can be achieved by defining a model at a higher
level of abstraction, where we deal in entities such as 'Business Event'
and 'Business Event Flow Rule', where Order and Invoice etc are
instances of 'Business Event', and 'Order must preceed Invoice' or
'Order optionally preceeds Invoice' are instances of 'Business Event
Flow Rule'. This is how workflow systems as designed. However its a
nightmare for many people to set up as an accounting system, and instead
common business domain expertise is expected to be encoded (enforced in
code) into an accounting system to some degree. Its all a question of
how many,  how tight and therefore how restrictive those rules are.

> Ok, let us define the document states:
> 
> An invoice is a document which states that the goods and services have
> been provided at a specific price.
(Continue reading)

David Bandel | 29 Apr 18:04 2007
Picon

Re: Redeveloping the system - was Thoughts on payment handling in 1.4.x

On 4/29/07, David Tangye <davidtangye@...> wrote:
> On Fri, 2007-04-27 at 19:47 -0700, Chris Travers wrote:
> > Actually, I would slightly quibble with this point.  Rather than
> > define terms precisely (since natural language is descriptive rather
> > than prescriptive), it is a good idea to discuss what we mean by what
> > we say and challenge eachother to find better words.  But we see the

Folks,

I think we're picking nits that aren't really addressing our needs.
Sets/members/tuples, tables/columns/rows, financial/legal.  Let's put
all this aside for a moment.

What we (hopefully) are trying to do is design a system to allow us to
track things of interest to us (trees).  So we need to define in needs
in terms of what it is we want to track.  I don't care if an order is
a legal, financial, or both transaction.  I need to know what I want
to track regarding the transaction. Defining all the separate items I
want to track and the relationships between them will help me decide
how to build:  the database, the input screens, the output screens
(the forest).

I want to be able to enter requests for quotes to vendors (who, what,
quantity needed).
I need to enter quotes (who, what, quantity, price/discount, shipping)
I need to enter orders (who, what, quote reference, price, etc.) based
on quotes.
I need to enter inventory (what/quantity/serial # received) against an order
I need to capture back orders, cancel unfulfilled orders, etc.
I need to check vendor invoices against orders and inventory received
(Continue reading)

Chris Travers | 29 Apr 19:52 2007
Picon

Re: Thoughts on payment handling in 1.4.x

On 4/29/07, David Tangye <davidtangye@...> wrote:
> On Sat, 2007-04-28 at 09:40 -0700, Chris Travers wrote:
> > Hi Ed;
> >
> >
> > > I can't help wondering if the current Quotes/Order/Invoice model isn't
> > > slightly too few states for some business.
> > >
> > > My model is: [snip]
> Its a bit of a problem in a way, that the implied business operational
> model and rules is one cast-in-stone set from the mind of one sql-ledger
> creator, who has been noted for uttering such sentiments as 'this is how
> business should work'.

I didn't get that feeling from Ed's email.  I thought he was saying
"here is how my process works" and we need to be able to support
(custom solution-wise or by default) his process.

> While it does work for a good % of folks, it does
> not suit many others. It always occurred to me that a little more
> flexibility would be nice in some cases.

Well, I think we need to separate out the base-line target from the
platform.  We ought to have LedgerSMB be a *platform* for accounting
solutions as well as a nice solution in itself fr many users.

The reason for making the application handle a single common case very
well but allow for add-ons, customizations by implementors, etc. is
that many vertical markets have special requirements.  If a truck
repair shop needs to store VIN's on invoices, we don't want everyone
(Continue reading)


Gmane