Re: [WebERP-developers] FormDesigner.php

[Tim S. <tim...@gm...>]

Hi Phil,

On 14 November 2013 08:54, Phil Daintree <ph...@lo...> wrote:
>
> 1. I feel that the form designer as it stands is very limited  - it is
> not easy to get the form designed exactly as you wish it to be ... there
> is a lot of trial and error and it is hit and miss - anyone messing
> around with formats using the form designer I am confident will come
> away cursing and frustrated.

The form designer was based on the Sage Line 100 form designer that I
happened to have a manual for sitting on my bookshelf at the time. It
does work, I know of many customers of ours who use it without coming
away cursing and frustrated, and I am confident they are not alone.
Yes of course it can be improved upon, all software can be improved
upon. This is open source, and you are welcome to improve on any
aspect of the code. The point I have made before is don't take out
code that is used by many users without putting in something better,
and that has at least the equivalent functionality.

It would be nice to have a pure WYSIWYG solution using JavaScript, but
at the time our policy was not to use JS in any major way.

> 2. Many businesses have unique requirements for their invoice layout ...
> say they wish to move the boxes to different places or different sizes
> with some new boxes, with different radius curves or square boxes,
> different fonts/sizes/colours have three images in different spots, with
> additional text explaining terms and conditions etc etc or put another
> way there really are the endless ways in which a business will wish to
> modify their invoice layout and the form designer ends up being a
> limitation rather than an advantage.

Yes it would be great to have the form designer extended to have these
things, why not add them?

> 3. To actually achieve the customised design that the customer actually
> really wants will still entail getting into the code and the code for
> form designer forms is WAY more complicated than the existing standard
> scripts - which are nice and readable with minimal abstraction, long
> variable names  etc etc ... it is actually quite easy to modify the
> standard scripts to make the layout exactly as the customer requires
> using the standard forms as a base.

Well changing the code has two big disadvantages. Firstly it creates a
massive headache on doing upgrades, requiring a level of knowledge of
patching files that is way above the ability of most business people.
Secondly many organisations have more than one company in their webERP
setup, and would like different formats for each company. One of the
principle aims of the form designer is to facilitate this, allowing
the same standard code to be used for all companies, but with a
different form layout for each.

> 4. The data for the reports is stored outside the database in xml files,
> creating another dependency on external data files. If we were to go
> with customisable reports I would prefer the data to come from the
> database like all other company data.

I agree with you the database is always the preferred place, but I
spent a long time trying to figure out how to design the database to
get this in. The only way I could see was complex and unwieldy whereas
the xml file is simple and easily understood. Surely we should say
that the data should be in the format that is most easily used and
understood rather than dogmatically saying it has to be in the DB
regardless of the complexity?

>
> Point 4 aside, I really do prefer the readable simple solution ... even
> though it appears to reduce the apparent functionality - actually it
> provides the ultimate in flexibility afforded by the much more
> approachable code.

Are we saying that webERP should be limited to ONLY those users who
feel comfortable modifying code? Surely it would also be good to have
a solution for those who don't?

>
> However, the key point I think you make Jo is this:
>
> "This then requires maintaining separate files for each client and
> maintenance/upgrades become more and more laborious."

Surely this is a strength not a weakness? It means that each company
can have its own design and there is no need to be constantly changing
the code depending on which company is being used?

>
> I do agree it would be super to address this problem which is not
> limited to just the reports, with some separate directory for modified
> scripts under the companies directory - which is looked for first before
> the standard script somehow to remove this issue. I am not sure how to
> implement this but I do think this would be a great addition and the
> better way to resolve this situation rather than creating complicated
> scripts to produce reports with very limited and awkward flexibility.

That would be great Phil, though it sounds complex to do. You are volunteering?

>
> Phil

Thanks
Tim




-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2