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,
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 listdevel@lists.ledgersmb.orghttps://lists.ledgersmb.org/mailman/listinfo/devel
devel mailing list devel@lists.ledgersmb.org https://lists.ledgersmb.org/mailman/listinfo/devel
Hi,
The first thing that came to mind while reading this was the Dancer path structure. So I came to the same conclusion as Erik, we should design it and then move the files to proper locations, otherwise there will be work duplication.
We do have files that are really static and could be served as is and other for which Templating is required. The structure should facilitate handling both cases by the appliaction and the developers
Yves
Le 2017-08-12 à 10:42:13, Erik Huelsmann a écrit :
Hi,
On Sat, Aug 12, 2017 at 10:48 AM, David G <lsmbdev@sbts.com.au mailto: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 http://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 <http://efficito.com/> -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ devel mailing list devel@lists.ledgersmb.org <mailto:devel@lists.ledgersmb.org> https://lists.ledgersmb.org/mailman/listinfo/devel <https://lists.ledgersmb.org/mailman/listinfo/devel>_______________________________________________ devel mailing list devel@lists.ledgersmb.org <mailto:devel@lists.ledgersmb.org> https://lists.ledgersmb.org/mailman/listinfo/devel <https://lists.ledgersmb.org/mailman/listinfo/devel>-- Bye,
Erik.
http://efficito.com 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
Hi,
The first thing that came to mind while reading this was the Dancer path structure. So I came to the same conclusion as Erik, we should design it and then move the files to proper locations, otherwise there will be work duplication.
Looking at Dancer's directory structure, it has two sibling directories:
- public/ - views/
where the public/ directory contains the static files to be served and views/ contains the snippets. There's a third directory views/layouts/ where the page skeletons are stored in which the snippets from the other files in views/ are being interpolated.
When trying to apply this to our UI/ directory, I'm seeing that the directory layout largely parallels David's proposal, except that the html snippets go into views/ and the CSS+JS don't. I'm thinking the mapping could work out as follows:
UI/js/ UI/css/ UI/js-src/ UI/img/
which would model the public stuff; then we'd have: UI/views/layouts/{login,logout,main,setup}.html UI/views/assets/ UI/views/contacts/ etc.
optionally, when we start using Sass to write CSS, we'd also have UI/scss/
making the immediate UI/ directory listing look like:
UI/ css/ img/ js/ js-src/ scss/ views/
with views/ subdirectory's listing as specified above.
Would that be a reasonable reorganization of our UI/ tree?
Regards,
Erik.
We do have files that are really static and could be served as is and other for which Templating is required. The structure should facilitate handling both cases by the appliaction and the developers
Yves Le 2017-08-12 à 10:42:13, Erik Huelsmann a écrit :
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 listdevel@lists.ledgersmb.orghttps://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.
devel mailing listdevel@lists.ledgersmb.orghttps://lists.ledgersmb.org/mailman/listinfo/devel
devel mailing list devel@lists.ledgersmb.org https://lists.ledgersmb.org/mailman/listinfo/devel
Hi,
I think it would do very well. The focus is well defined and easy to grasp for the developers and serving statics would be easy to set. The initial separation between UI and App was to split 2 functionalities, this adds static and dynamic UI, while moving toward a structure where Dancer will fit.
Ok for me.
Yves
Le 2017-08-26 à 11:17:20, Erik Huelsmann a écrit :
Hi,
The first thing that came to mind while reading this was the Dancer path structure. So I came to the same conclusion as Erik, we should design it and then move the files to proper locations, otherwise there will be work duplication.Looking at Dancer's directory structure, it has two sibling directories:
- public/ - views/
where the public/ directory contains the static files to be served and views/ contains the snippets. There's a third directory views/layouts/ where the page skeletons are stored in which the snippets from the other files in views/ are being interpolated. When trying to apply this to our UI/ directory, I'm seeing that the directory layout largely parallels David's proposal, except that the html snippets go into views/ and the CSS+JS don't. I'm thinking the mapping could work out as follows:
UI/js/ UI/css/ UI/js-src/ UI/img/
which would model the public stuff; then we'd have: UI/views/layouts/{login,logout,main,setup}.html UI/views/assets/ UI/views/contacts/ etc.
optionally, when we start using Sass to write CSS, we'd also have UI/scss/
making the immediate UI/ directory listing look like:
UI/ css/ img/ js/ js-src/ scss/ views/
with views/ subdirectory's listing as specified above.
Would that be a reasonable reorganization of our UI/ tree?
Regards,
Erik.
We do have files that are really static and could be served as is and other for which Templating is required. The structure should facilitate handling both cases by the appliaction and the developers Yves Le 2017-08-12 à 10:42:13, Erik Huelsmann a écrit :Hi, On Sat, Aug 12, 2017 at 10:48 AM, David G <lsmbdev@sbts.com.au <mailto: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 <http://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 <http://efficito.com/> -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ devel mailing list devel@lists.ledgersmb.org <mailto:devel@lists.ledgersmb.org> https://lists.ledgersmb.org/mailman/listinfo/devel <https://lists.ledgersmb.org/mailman/listinfo/devel>_______________________________________________ devel mailing list devel@lists.ledgersmb.org <mailto:devel@lists.ledgersmb.org> https://lists.ledgersmb.org/mailman/listinfo/devel <https://lists.ledgersmb.org/mailman/listinfo/devel> -- Bye, Erik. http://efficito.com <http://efficito.com/> -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ devel mailing list devel@lists.ledgersmb.org <mailto:devel@lists.ledgersmb.org> https://lists.ledgersmb.org/mailman/listinfo/devel <https://lists.ledgersmb.org/mailman/listinfo/devel>_______________________________________________ devel mailing list devel@lists.ledgersmb.org <mailto:devel@lists.ledgersmb.org> https://lists.ledgersmb.org/mailman/listinfo/devel <https://lists.ledgersmb.org/mailman/listinfo/devel>-- Bye,
Erik.
http://efficito.com http://efficito.com/ -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
participants (3)
-
David G -
Erik Huelsmann -
Yves Lavoie, GaYLi