Hi,

On Sat, Aug 12, 2017 at 10:48 AM, David G <lsmbdev@sbts.com.au> wrote:

I agree that a better organization of files in the UI subtree would be desirable.
I haven't gone for a specific look yet, but I'm envisaging a dir tree that closely matches the "functional" use of each levels content.
so something loosely along the lines of....
- UI/app/{login,logout,main}.{html,js,css}
- UI/app/ar/*.*
- UI/..........
- UI/setup/*.*
- UI/lib/*.*

Hmm. It seems we roughly have something like that, but not quite: your grouping puts the files which are part of the "main" application into the UI/app/ directory. Our current "LedgerSMB/Scripts/" directory doesn't group them that way. Your further ordering is by module which uses them. That seems to be in line with our current directory layout, with the exception of the Reports/ hierarchy which collects all reports across function-areas.

Thinking about this more, I come to the conclusion it probably has a lot to do with how we structure our tree when switching to Dancer with nice URLs and routes. We'd probably want to have a directory structure which closely resembles the URI structure for the routes we'll be creating.

Considering the above, I'm thinking that short-term I made an improvement by deleting 16 unused files (see below) and that we can delete 3 more unreferenced ones (UI/info.html, UI/approved.html and UI/corrections.html and 7 more (UI/am-*.html) by moving am.pl onto new code and LedgerSMB::Report.

Other than that, we may need to look at the structure more when we're going to re-arrange the tree when moving more to Dojo, Dancer and Services.

Note that I've just merged a PR which deletes 16 unused files in total, 12 from the top-level UI/ directory, which cleans things up quite a bit (many of the deleted files were used by now-removed old/bin/*.pl modules).

On 11/08/17 22:34, Erik Huelsmann wrote:
Hi,

Since we moved to being a single-page app on the main app, I'm looking to improve clarity in the UI/ tree.

What's the problem? I see a number of things being unclear:

* Out of all the files stored in UI/, only these are actual "top level" documents:

   - UI/login.html

   - UI/logout.html

   - UI/main.html

   - setup/*.html

* All files, also the bits that are "html fragments" these days, include a full html start- and end-tags as well as a header definition (which are being thrown away upon receipt!)

* There are non-HTML documents (ODS, XLS, CSV, ...) in that directory (which suggests that it's not solely about UI, but also about data-export/report generation)

Apart from the mix of HTML documents, the directory contains assets that *are* being served: javascript/images/css/... .

Should we separate the HTML fragments in order to clarify the status as being a "non-toplevel document"?

Another thing: I think we should separate out the templates which have not *just* an HTML representation, meaning that they are not (primarily) UI related elements.

Regards,

--

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.
_______________________________________________
devel mailing list
devel@lists.ledgersmb.org
https://lists.ledgersmb.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@lists.ledgersmb.org
https://lists.ledgersmb.org/mailman/listinfo/devel

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.