Hi all,
Let me start out by expressing my happiness that we're having the
discussion of which frameworks to use and where the LSMB UI should go.
Personally I greatly value discussions like these because they interest in
LedgerSMB and a general drive to improvement as well as a way for
developers and community to reflect on what's considered improvement.
Now regarding the thread itself, I'm seeing two topics being discussed
which might actually need separate treatment.
1. Short-term improvement to the Customer/Vendor account screen and GL
transaction entry screen required to
a) make LedgerSMB's UI match that of the user's expectations (ie. make the
Customer/Vendor screen show actual Tabs, not just make links work like they
are)
b) Fix the 1.4 customer/vendor screen - which didn't work at all beyond
the Company and Account tabs until John's recent commit
2. Longer term general direction for the development of the LedgerSMB UI
This point probably requires separate discussion, because the direction
taken to develop a UI inherently affects the efforts required for the "back
end". I.e. whether we from here on *only* develop services on the back end,
with separate front-end developments, or that we develop along the current
route which supports to build a rich front-end "eventually".
On the first point (short-term interface developments, notably LedgerSMB
1.4 [and 1.3 backports?]) I see that Brian has developed custom extensions
for LedgerSMB, using Scriptaculous, because that's what we are currently
using. From John I understand that Dojo doesn't "pollute" the global
namespace, so it could harmlessly co-exist with Scriptaculous.
If that's the case, I can see there being a case for replacing the two or
three places where we currently have JS code with Dojo based code. Brian's
Scriptaculous code won't be affected and can be used in parallel.
As far as "LedgerSMB coming with Scriptaculous" is concerned, I'll add a
section to INSTALL telling packagers to depend on the packages readily
provided by their distribution to provide Scriptaculous/Dojo/jQuery/etc:
these packages are updated for bug- and security fixes, something we can't
all keep track of. Which means to me: we should probably separate the
scriptaculous dependency out into its own TAR file which can be untarred
over a tar which holds the base LedgerSMB code, if the user wants it. This
makes the dependency more apparent and prevents packagers from accidentally
packaging an additional JS framework.
Comments?
Regarding the second subject, I'd like to start a separate thread to see
who could and would want to contribute to what. From there, we can probably
define the direction which can have the most developers behind it to
achieve both the most satisfying result to the (then) active contributors
*and* to get the most out of our community.
Note that this is just my idea and that I think all community members
(active contributors, lurkers and potential users alike) should have a say
in this. Although I do think that the people actually writing the code
(currently or new contributors) get the final votes. I'll write a separate
mail to kick off technical discussion on the second subject (long term UI
direction).
What do you think?
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
