>$Item->move_item($StkMoveNo, true);
>
>where is the move_item method I expected to be in the DefineCartClass.inc -
>can't see it anywhere was looking forward to seeing how this was processed.
>(sicko!)
>
>
It is in GenericStockItem.php.
>Your MiscFunctions script -I do have some reservations as I guess you would
>expect. I reckon one function would be fine - even then have a question about
>whether its worth it - for the PrintMessage stuff but you have 10 separate
>functions!!
>
>
>My weird criteria for functions/includes is based on the fact that using a
>function or include requires the reader of the code to look elsewhere to
>figure out what's going on - so there is a cost in excessive use ... it is
>labour intensive for someone else to read/understand the code! Against that I
>really do understand that there are some big pluses for maintenance and
>reducing code/typing where there are heaps of possibilities for re-use. Where
>the latter clearly outweigh the former .... lets go, otherwise lets not!!
>
>So if we are replacing ...
>
>include("includes/footer.inc");
>exit;
>
>with an endWEBERP() function - I can't see the point.
>
>or 10 PrnMsg functions to replace an echo statement? .... Nah!
>
>On the other hand your variable initation stuff is clearly a significant
>saving of typing which appears again and again - its a sitter I should have
>seen before. Same with the DB_query stuff - great!
>
>I hope this makes sense and that my eccentricities are not too much to live
>with!
>
>
I know it seems like alot, but these things offer alot of functionality
and part of the point of the print messages is to more easily allow
uniform error/warn/info/etc. messages. That applies to theme/style
changes as well, which makes it quite easy when you want to change it.
More so, as you've realized, it makes readability and maintenance on
the code much much easier and simply cuts down on duplicating code. For
example - if I look at a print/echo, I have to read it to figure out
what's happening, what it's going to look like, etc - prnErrMsg tells me
at a glance. With the endWEBERP() - again, painfully obvious what's
happening - and what if we find later that something else is necessary
in the 'shutdown' process? In all these case, you get 1 central place to
change things (or have problems track back to) rather than having to fix
it every place it was used (and hoping you found them all).
I understand the ease you feel in having all the code in one file, but
you may want to take a step back and rethink that in some of these
cases. If you come to the same conclusion, can we at least leave that
stuff in there for me and anyone else who finds using these things
helpful? I know I tend to bury stuff, but I usually work real hard on
making it work well before I do... many developers do things like you've
seen me do - having it accessible (even if not strictly used) will also
help some new contributor ramp up quicker. Believe me from having just
done it - it took alot of work to figure out what was happening in
places - much of that is necessary - what I've pulled out are things
that I did not want to have to think about/look at again. Documentation
of the functions used, almost api docs, is probably needed.
This is also part of the reason I use PHP instead of, say, writing nasty
C based CGI scripts - many of it's functions/variables cover up things
that I simply do not need to mess with, but when I do, I still can.
|
