refactor all the things

[digitalkaoz]

ok this PR is quite huge and changes nearly everything... look at this demo to get an idea: http://dashboard.digitalkaoz.net/

we use digitalkaoz/issues for search and fetching projects and issues from different issue trackers (currently implemented are github and jira, could be extended to for e.g. gitlab)

we use digitalkaoz/issues-bundle for the symfony layer and persisting data retrieved from the "issues" library in a storage agnostic way (currently only elasticsearch, but e.g. doctrine should be a nobrainer) this bundle also contains the sync and search commands

all other bundles are obsolete...because the whole filtering and layouting is done by a reactjs + cortexjs application. its quite cool, no reloading, live filtering issues...

the styling is completely refactored to a sass variant

the project configurations has changed to a more simpler approach:

        github:
            - dbu/dashboard                             # explicit repo
            - phpcr/*                                   # all user/org repos
            - symfony/[Console|Debug]+$                 # only symfony/Console or symfony/Debug
            - doctrine/(?!common|lexer)([a-z0-9\.-]+)$  # all but doctrine/common or doctrine/lexer
        jira:
            # jira is a bit special, create this string with app/console issues:jira-crypt
            - ENCRYPTEDSTRING https://jira.domain.com PROJKEY

frontend deps are managed by npm and bower so for building the application you need this tools globally installed on your system.

everything is more decoupled and focused on one thing.

the mobile fixes could need some love.

i think the whole refactoring could be a good base for further feature additions

[cordoval]

:+1: deal with it

[stof]

I see a few issues in the interface:

• when filtering issues or PRs, the number near the repo name is not updated, making the UI confusing when it tells you there is 3 elements but uncollapsing it displays 2 issues.
• the owner filter is misleading. It is actually filtering based on the author
• the state filtering with only the open state is weird
• the behavior of the filter dropdowns is confusing. Clicking anywhere else on the page should probably close it. It is more common.
• greying repos when they don't match the search is confusing, because it means the user still needs to search manually for matches. The repos matching the criteria are not even moved to the top.

[stof]

@digitalkaoz please write the readme of your bundle instead of putting //todo in it. It would be better for shared bundles, especially once you start using it in other projects

[dbu]

• the state filtering with only the |open| state is weird

i thought about adding closed issues too, but this requires the import to have paging working well, as chances that there are more than the api limit of issues in total is rather high. actually, it would probably need incremental sync to avoid expensive and pointles syncing of already closed issues.

• greying repos when they don't match the search is confusing, because it means the user still needs to search manually for matches. The repos matching the criteria are not even moved to the top.

this is with the spirit of what i had before. i am really unsure what is better. i guess updating the order to have repository with no matches at the bottom is the best idea.

my order was non-deterministic. we could order alphabetically i would say.

for the pull / issue filter, i think an interface element with just one click would be better. maybe checkboxes [ ] issues, [ ] pulls and both checked by default. and unchecking the last checking the other.

btw, the filters only get active once i sort issues. same for expanding a repo. (firefox)

as project maintainer, i liked the mouseover preview of the issue description when moving over the issue. while your interface is more cleaned up, i need a lot more clicking to see things.

[dbu]

What about having the functional frontend in IssuesBundle too? And only CSS here? Would make it easier to clone the project for a new instance.

----- Reply message ----- Von: "Robert Schönthal" [email protected] An: "dbu/dashboard" [email protected] Betreff: [dashboard] refactor all the things (#27) Datum: Fr., Okt. 3, 2014 00:29 ok this PR is quite huge and changes nearly everything...

look at this demo to get an idea: http://dashboard.digitalkaoz.net/

we use digitalkaoz/issues for search and fetching projects and issues from different issue trackers (currently implemented are github and jira, could be extended to for e.g. gitlab)

we use digitalkaoz/issues-bundle for the symfony layer and persisting data retrieved from the "issues" library in a storage agnostic way (currently only elasticsearch, but e.g. doctrine should be a nobrainer)

this bundle also contains the sync and search commands

all other bundles are obsolete...because the whole filtering and layouting is done by a reactjs + cortexjs application. its quite cool, no reloading, live filtering issues...

the styling is completely refactored to a sass variant

the project configurations has changed to a more simpler approach:

github:

• dbu/dashboard # explicit repo
• phpcr/* # all user/org repos
• symfony/[Console|Debug]+$ # only symfony/Console or symfony/Debug
• doctrine/(?!common|lexer)([a-z0-9.-]+)$ # all but doctrine/common or doctrine/lexer jira:

  jira is a bit special, create this string with app/console issues:jira-crypt

• ENCRYPTEDSTRING https://jira.domain.com PROJKEY

frontend deps are managed by npm and bower so for building the application you need this tools globally installed on your system.

everything is more decoupled and focused on one thing.

the mobile fixes could need some love.

i think the whole refactoring could be a good base for further feature additions

You can merge this Pull Request by running git pull https://github.com/digitalkaoz/dashboard refactorings Or view, comment on, or merge it at: https://github.com/dbu/dashboard/pull/27

Commit Summary

refactor all the things

File Changes

M .gitignore (11)

A Capfile (4)

D Makefile (3)

M README.md (60)

M app/AppKernel.php (6)

D app/Resources/js/jquery-1.9.1.min.js (5)

A app/Resources/jsx/app.js (29)

A app/Resources/jsx/components/dashboard.jsx (66)

A app/Resources/jsx/components/filter-bar.jsx (50)

A app/Resources/jsx/components/filter-field.jsx (44)

A app/Resources/jsx/components/filter.jsx (61)

A app/Resources/jsx/components/issue.jsx (78)

A app/Resources/jsx/components/nav-controls.jsx (57)

A app/Resources/jsx/components/navigation.jsx (35)

A app/Resources/jsx/components/project.jsx (149)

A app/Resources/jsx/components/projects-container.jsx (34)

A app/Resources/scss/dashboard.scss (175)

M app/Resources/views/base.html.twig (32)

M app/SymfonyRequirements.php (96)

M app/check.php (148)

M app/config/config.yml (82)

M app/config/config_dev.yml (5)

A app/config/deploy.rb.dist (35)

M app/config/parameters.yml.dist (40)

M app/config/routing.yml (13)

D app/config/twig.yml (5)

M app/console (2)

A bower.json (22)

D components/jquery/jquery.js (9597)

D components/require.css (0)

M composer.json (48)

D composer.lock (2032)

D doc/images/dashboard_screenshot.png (0)

D doc/images/dashboard_screenshot_tn.png (0)

D doc/issue.dump (877)

D doc/pull.dump (82)

D doc/repository.dump (174)

D elasticsearch-head (1)

A gulpfile.js (140)

A package.json (55)

D src/Dbu/DashboardBundle/Controller/DefaultController.php (285)

D src/Dbu/DashboardBundle/DbuDashboardBundle.php (9)

D src/Dbu/DashboardBundle/DependencyInjection/Configuration.php (28)

D src/Dbu/DashboardBundle/DependencyInjection/DbuDashboardExtension.php (28)

D src/Dbu/DashboardBundle/Resources/config/routing.xml (10)

D src/Dbu/DashboardBundle/Resources/config/services.xml (20)

D src/Dbu/DashboardBundle/Resources/less/dashboard.less (58)

D src/Dbu/DashboardBundle/Resources/public/images/issues.png (0)

D src/Dbu/DashboardBundle/Resources/public/images/pulls.png (0)

D src/Dbu/DashboardBundle/Resources/public/x.js (46)

D src/Dbu/DashboardBundle/Resources/views/Default/datefilter.html.twig (18)

D src/Dbu/DashboardBundle/Resources/views/Default/index.html.twig (55)

D src/Dbu/DashboardBundle/Resources/views/Github/emptyRepository.html.twig (3)

D src/Dbu/DashboardBundle/Resources/views/Github/issues.html.twig (24)

D src/Dbu/DashboardBundle/Resources/views/Github/repository.html.twig (44)

D src/Dbu/DashboardBundle/Resources/views/Github/repositoryList.html.twig (25)

D src/Dbu/DashboardBundle/Resources/views/Github/statusBadge.html.twig (17)

D src/Dbu/GhCollectorBundle/Command/DumpCommand.php (156)

D src/Dbu/GhCollectorBundle/Command/SynchronizeCommand.php (89)

D src/Dbu/GhCollectorBundle/DbuGhCollectorBundle.php (9)

D src/Dbu/GhCollectorBundle/DependencyInjection/Configuration.php (25)

D src/Dbu/GhCollectorBundle/DependencyInjection/DbuGhCollectorExtension.php (28)

D src/Dbu/GhCollectorBundle/Github/Synchronizer.php (193)

D src/Dbu/GhCollectorBundle/Resources/config/services.xml (33)

M web/.htaccess (11)

M web/app.php (2)

M web/app_dev.php (2)

D web/config.php (124)

A web/img/jira_icon.gif (0)

Patch Links:

https://github.com/dbu/dashboard/pull/27.patch https://github.com/dbu/dashboard/pull/27.diff

— Reply to this email directly or view it on GitHub. {"@context":"http://schema.org","@type":"EmailMessage","description":"View this Pull Request on GitHub","action":{"@type":"ViewAction","url":"https://github.com/dbu/dashboard/pull/27","name":"View Pull Request"}}

[stof]

i thought about adding closed issues too, but this requires the import to have paging working well, as chances that there are more than the api limit of issues in total is rather high.

Well, if closed issues are not synced in the dashboard, the filter should be removed from the UI, as it has no effect

[digitalkaoz]

whoopwhoop thanks for all your feedback, this PR wasnt intended to be the perfect and final solution, but your arguments are valid...so now it must be made perfect ;)

gimme some time...thanks for the feedback on issues/issues-bundle aswell, thats the more critical parts...the frontend issues could be solved easily i think...

now enjoy your sunny weekends as i do ;)

[digitalkaoz]

ok i polished this PR...the digitalkaoz/issues and the bundle digitalkaoz/issues-bundle should be fine now...most of the frontend issues are resolved.

except sorting...i implemented it (only matching projects on top) but it felt weird because i have to constantly search for a specific project) //ping @dbu @stof

[dbu]

looks interesting! sorry, i don't have the time to look at this this week. but will do next week. can you update the readme with setup instructions? i guess i need npm and stuff to have gulp and bower, right? (btw, having not much clue about this, why do we need both bower and gulp, arn't both doing the same kind of service?)

[digitalkaoz]

i linked to the issues-bundle docs, everything is explained there...

gulp is a task runner bower is dependency manager like composer for css/js stuff npm is a dependency manager like composer for nodejs libs

but the whole frontend toolchain isnt necessary at all, i put it in this project to be able to develop the parts...if including the bundle in production you wont need them

[digitalkaoz]

updated the ui according filters and non matching projects (will be hidden), as the issues are loaded on demand, unloaded projects are greyed out

latest changed are deployed here: http://dashboard.digitalkaoz.net/

[dbu]

seems i don't get to check this out in detail. see you later this week in berlin :-)

one question though: does it make sense to mirror the issues into ES at all? all search happens in the frontend now, right? (i am kind of attached to the ES search as it was my original motivation for this thing, to try out ES on a real usecase :-) . but apart from that, what about bandwidth? i always thought about ajax-ing the issue details on mouseover to not have the dashboard page be huge...)

[digitalkaoz]

hey i think a storage is necessary for a good performance, but not tied to Elasticsearch (could even be Array or Doctrine)

everything is ajaxified ;) projects + issues

but yeah, lets meet tommorow :)

[dbu]

hi robert, so we did not work on this at the hackday. what about a very first step where you just migrate this project to use the library and bundle you factored out? maybe even with shared knowledge in here to do the elasticsearch queries. that should not be too hard to wrap up i hope, and then we can merge something already.

then we can see again what search / filtering should happen in the frontend and what needs the backend.

[digitalkaoz]

mh, you mean the old frontend, and the new backend? or only move the filtering into the backend?

[dbu]

yeah, i meant keeping the old backend. not as a permanent solution, but just as a very first step.

[dbu]

next step will then be the new frontend and figuring out what search to do in front and what in backend.