A social-governance and direct-democracy online software that cements power to the local level, while enabling only information-sharing and administrative functionality to networked groups and teams spanning geographic regions larger than the local.
Even though I'm using Laravel for the backend, I've avoided relying too much, if at all, on model relationships and the elegant, expressive code they afford, for my database queries. My goal has been to go to disk as little as possible ... for performance reasons. Hence the tortured scripts fetching complex data structures from multiple tables, and the formatting scripts – all in the App/Actions folder with model-name subfolders – that compile that complex data into arrays I return to InertiaJs/Vue. In other words, the philosophy I've chosen, in all my amateur enthusiasm, favours the end user and thus also response times over code maintainability to some degree. Code maintainability is very important to me, almost a joint top priority with usability, response times and resource efficiency, but I do sacrifice it to user satisfaction as just described.
we4v's check-form-completion system is very complicated indeed; I thought I'd better sketch out its elements here.
In manageModals.js, which is in ./resources/js/Pages/Composables/manageModals.js
, there are four methods handling the checking system I've set up to enable/disable each form's submit button, and apply the styles that indicate visually the enabled and disabled states, handled via the boolean variable greyButtonEnabled
, which is passed to the relevant Vue component via a prop. (Forms in we4v are overwhelmingly delivered within modals.) These are the names of the relevant methods with descriptions:
-
checkIfUserMaySubmit(mode)
: Runs checks usinggetElementById
by taking amode
variable that carries strings such as 'group' or 'team' to set the CSS ids. Once all the boolean variables have been set, it then determines whether the relevant submit button should be enabled or disabled. -
checkIfProjectGroupSelected()
: Like it says on the tin. When creating a new Project, it must be assigned to a Group to be submitted. -
checkIfRoleInputFieldsFilled()
: Groups and Teams have members, and members (Associates) have roles. If, when clicking a checkbox to invite a specific Associate to join a Group or Team, the user fails to enter a string into the Role input field, or fills the text field but fails to click its corresponding checkbox, the border of that field is coloured red and the submit button either remains disabled or is changed to disabled. This method plays a major role in that calculation. Thie method is a shell method, so to speak, that calls the workhorsescheckRolesAgainstAssocs()
andcheckAssocsAgainstRoles()
, before finally callingcheckIfUserMaySubmit(mode)
described in point 1. above. -
checkIfTaskAssigneeSelected()
: To be completed.
Next up are the methods and variables in MyGroups.vue:
-
addRemoveAssociate(mode, user_id_role)
: This method primarily adds or removes associates to/from an array/object that is then comsumed by bothsubmitGroupData()
andsubmitTeamData()
to save/update Groups/Teams and their member details. It is 'borrowed' by the check-form-completion system to fire the methodscheckIfRoleInputFieldsFilled(user_id_role)
andcheckIfUserMaySubmit(mode)
every time a user clicks an Associate checkbox. -
onCollectMemberRoles()
: Every time a user exits focus from one the role input fields, this method is called. It toggles the boolean variableselectedAssoc
, assigns a user_id to the variableroleUserId
, then calls the methodcheckIfRoleInputFieldsFilled(user_id)
. This latter method has to be called every time a determination must be made as to what colour border the role input field ought to display. The truthiness ofselectedAssoc
is needed for: -
watch(selectedAssoc)
: Not strictly a method, but every timeselectedAssoc
changes state, this method has to be fired. It sets the role-input-field's border colour.
Next up are the methods and variables in MyProjects.vue:
(To be completed)
Finally, the DOM data and triggers/variables therein:
-
Vue component
Input.vue
forgroupName
,groupDescription
,teamName
andteamFunction
: Fires@check-if-user-may-submit="checkIfUserMaySubmit('group/team')"
on blur in theMyGroups.vue
page. Ditto forMyProjects.vue
with its 'project' and 'task' modes, names and descriptions, start and end dates, etc. CSS ids are critical here::id="'groupName'"
,:id="'groupDescription'"
,:id="'teamName'"
,:id="'teamFunction'"
, etc. See code in methodcheckIfUserMaySubmit()
inmanageModals.js
to see whatid
values are required. -
Standard HTML input for Associate checkboxes:
@click="addRemoveAssociate('group', associate.user_id), selectedAssoc = !selectedAssoc, roleUserId = associate.user_id"
. SeeaddRemoveAssociate(mode, user_id_role)
above. The CSSid
of these elements is critical::id="'checkbox_'+associate.user_id"
. -
Vue component
InputNoLabel.vue
: Calls@collect-member-roles="onCollectMemberRoles"
on blur. See eponymous point 2. above. CSSclass
is critical:class="assocRoles"
, which becomesclass="assocRolesEdit"
for edit modals. -
Vue component
ButtonGrey.js
: Has to have the id 'submitForm', this per modal form.