-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
carmel-fe initial design #7
Comments
1. Simplest
|
1.1 editor toolbarToolbar elements (buttons) are bound to the auth0 user object which is provisioned by carmel administrator. At the moment we have two provisioned users: Note: this data is visible only when authenticated to Auth0. I suggest using this version of the toolbar, disregarding the content shown below ( having the image of the user is a nice detail for example Notes:
|
1.2 editing surfaceUntil someone comes up with a better solution, I propose this tag editor which will behave as shown below: |
1.3 Two level database updatesAs discussed between @JeroenVinke and @adriatic earlier today in gitter ☝️ April 1, 2017 12:36 PM, carmel editor has to implement the support for "delayed database updates", where user editing results with per/user database record and a "message" to the carmel administrator that there are edits that need to be merged in the database. Mimicking GitHub Pull Requests in a minimal fashion is probably the best way to do this quickly. This approach should be used the same way for the Tag editor, and for the more complex Component / Sample editor to be implemented after the Tag editor. |
Can we already say how the user model will look like? If we create different toolbars (or rather different buttons in the same toolbar) for brigde user and bridge editor we need to store user and claims/roles somewhere. This will probably be a Do we already have a concept of that? |
@adriatic Please have a look at my sample interface definition which should resemble your definition in this post. Let's see if I got your idea correctly. 😃 |
On security user modelAuth0 takes care of all that by persisting and providing the management ui for all security related data. This is why there is no such data in carmel-api SQL Server database. |
The editor will need to know which role is active, right? Sure, Auth0 will provide that information. My question was if we already have a model for that. It will supposedly be the one which Auth0 provides. Correct? |
Yes of course. While I am happy to be always "online" for Auth0 issues, I will also suggest what information to read in order to gain additional knowledge (this is always a good thing). In addition to providing "interactive" dashboard for manual provisioning of "everything" related to users and their rights / limitation, all this information is also available as API (so the application can do all that working itself, without having to have a human do it). As this could be more work than we can afford at this point, we should use the Dashboard based provisioning. |
on carmel editor modelI believe that there are a few attributes missing or incorrect:
@JeroenVinke - is there still something missing? |
I hope to get the basic aurelia navigation skeleton app (viewed as a SPA) authenticate itself to a basic web API server (work I am doing for Aurelia-Auth0 organization done for tomorrow. This would allow us to discuss the carmel issues in a more concrete context. |
Yeah, definitions for proposals, but those are not defined yet. We can add those as we go this week |
1.4 Authentication UII suggest to take the most standard approach and add the The user could decide to first click on the This approach allows access to some menu bar items that everyone can see ( We will of course customize this widget (offering GitHub based authentication by default, and id/password UI for administrators) |
We don't want changes to be visible on the catalog right away, we want the changes to be "proposals" and those proposals need to be merged before we show them on the catalog |
True - and at the same time, you might be mixing catalog UI with carmel UI; in this discussion, we are describing carmel app only (that does not mean that at some time we will not switch focus on catalog, of course). Unless we merge catalog and carmel into one app (something I would not favor), catalog ui should be nearly trivial, allowing "composite" search (often referred to as advanced search). |
I don't know why you think i'm mixing them up. Carmel (UI + backend) is the entity that should prevent changes from being visible on the catalog right away, without having someone merge the changes in Carmel. So a proposal system is something we do need to think about in the carmel UI
I never said anything about making changes to the catalog itself, I only talked about a system in Carmel that ensures that the data sent from carmel to the catalog has always been verified by a 3rd party. |
Are you a bit touchy today 😏 ? Note that I wrote the word might just to prevent such response (I do think ahead what reactions could I cause with my writing). At the same time, you are correct that there is more UI needed to address this "two step workflow", which I will document (as my proposal, only) within one hour, when I return to my office |
Why thumbs down emoji? |
1.5 Ideas for two - step editing workflowThe user who logs in with the GitHub account does not see any manifestations of this dual step approach - other than the message that appear once he/she clicks on the When the carmel admin logs in he will have an additional button on the tolbar that would open the page for accepting user created changes since last such action. This button should also show the number of pending changes to be approved - to indicate the "urgency" of this approval process. It would be nice if the admin actions ( Whoever believes that I am paying too much attention to details in the context of adding a simple tag - please be reminded that this whole exercise is really a practice for the aurelia / amazon compendium, where keeping contributors involved and informed is of a critical importance 😄 . |
@adriatic When you say every collection of tags right now should be an array of strings, do you mean you'd prefer to leave out the IDs for now? export interface IComponentTag {
cTag: string;
}
export interface ISampleTag {
tag: string;
}
export interface ISampleDefinition {
id: number;
name: string;
created: Date;
gist: string;
sampleTags: ISampleTag[];
}
export interface ICarmelSample {
name: string;
created: Date;
componentTags: IComponentTag[];
samples: ISampleDefinition[];
} |
@Thanood not sure what led you to believe that my today's description above has anything to do with using or not using IDs. Let me first restate what I wanted to indicate, using the screenshot below, which represents the begining of the definition of the The entity
I also want to address the presence and absence if integer IDs - please check this section for more information on this. |
reopened because it was closed by a bad click |
Is there any way to make the dropdown arrows point down? 😃 |
My guess is that this is either "prebuilt" into the |
There is one thing I don't get concerning tags and cTag: export interface IComponentTag {
id: number;
cTag: string;
}
export interface ICarmelSample {
name: string;
created: Date;
componentTags: IComponentTag[];
samples: ISampleDefinition[];
} The entity {
name: 'my-component-sample',
created: '20170403T00:00:00',
componentTags: [
{ id: 1, cTag: 'my-component' },
{ id: 2, cTag: 'kendo-free' }
]
} (please note that the second component tag is completely made up and probably doesn't make any real sense) I understood that If so, please point me in the right direction to understand a structure like this which will be the result if using an array of {
name: 'my-component-sample',
created: '20170403T00:00:00',
componentTags: [
{ id: 1, cTags: ['my-component', 'kendo-free'] },
{ id: 2, cTag: ['navigation', 'tool-bar'] }
]
} |
The structure of |
Good questions coming from the lack of clarity created by the switch where a tag was an object with elements like string, datetime, reference to an article outside of the carmel context etc. As this adds the difficulties related to serialization and deserialization, I changed the design to a lot simpler approach where a In the case of the component (where I knew that the related tag (array of strings) can be initialized by setting this array's "first" (zero-th) element to the name of the components) so, the code should be like this
Only by writing this I realized that I did not properly correct switch from the initial "complex tags" to "simple tags" - meaning that I have to really appologize to expose you to this "garbage". The structure at https://github.com/adriatic/carmelDbSeed/blob/master/node/code#L13 is the old version of the code, that I hid in https://github.com/adriatic "organization" to not create confusion in aurelia-ui-tollkits Thanks for persisting without asking me "are you aware how stupid this is, really?" 😏 Now, this requires immediate fix in the entity classes in the carmel-API and recreating of the database. Since I am clearly guilty of being careless, I will do this now, so you can find the correct pieces in carmel-API tomorrow. Please let me know if we see this the same way now. |
Thanks, @adriatic that clears up a lot. 😃 I will have another look at carmel-api tomorrow. |
Thanks for this ack 😄 The issue aurelia-ui-toolkits/carmel-api#3 is created a while ago, and I rechecked it a few days back, to ensure that is has no references to the previous organization (http://github.com/adriatic) where I worked on learning how to and to put together the initial version of what is today carmel-api repo. By saying
are you indicating that aurelia-ui-toolkits/carmel-api#3 has some incorrect references? |
This comment indeed has incorrect references: aurelia-ui-toolkits/carmel-api#3 (comment) The references forward to your personal repo where I found the old code. |
Step 2.2 - the node link: https://github.com/aurelia-ui-toolkits/carmelDbSeed/tree/master/node forwards to https://github.com/adriatic/carmelDbSeed/tree/master/node Step 2.3 - the "code" link: https://github.com/aurelia-ui-toolkits/carmelDbSeed/blob/master/node/code of course has the same forward. At least it does this for me. 😃 |
... and for me as well (any other possibility would really concern me a lot 😄). Fixed. |
I've successfully implemented the proposed tag editor (52e54e0) but I've seen some drawbacks:
I consider only the last one a major drawback. |
I agree on all drawbacks and we should address them all. My initial idea behind using that jQuery based version was to save the time until we can get some alpha version of carmel out, so we can really assess what level of enthusiasm it would generate. Based on that we can embark on a more serious solution, while still retaining all of the "captured" tags in the database.. I will update my local copy of carmel, so I can give more comments in the context of this discussion item |
All UI elements needs to be KendoUI of course - as otherwise having a cool feature like theme manager would make no sense.
This document starts with the basic shell:
which (shell) gives us "Catalog-compliant" navigation infrastructure. The green numbers 1 - 5 indicate the 5 clicks (in that order) that defined the "deepest" path to the context of basic use for scatter charts.
The rest of this article discusses the content of the green rectangle - the area in which all
carmel-fe
actions take place. Let's use the "handle"carmel editor
reference that area, which consists ofeditor toolbar
andediting surface
.The implicit assumption is that the context for the
carmel editor
is completely defined once the component (red markers 1, 2, 3 and 4) and sample (red marker 5) are selected. See testing carmel-api with postman section to find out more about fetching the editor context. In that situation the context forautocomplete
component is defined as:The text was updated successfully, but these errors were encountered: