Just thinking and a question round my mind. I use to code xaml using grid, easier for me, at least. Just define the grid and using its cells (span row and column and so on...).
Doing a web´s demo today I remember table´s tag is being obsolote and I am wondering, the same idea could be applied to grid in mobile´s app.
Thinking about it, absolute and relative layout are similar to div (web speaking) so we could deduce the right way to render the xaml should be using those kind of layouts...
What do you think guys? What advantages and deficiencies are coming on using those approaches? I want to get use to code thinking in the best way, not thinking about easyness of that (supposing, that benefit me in long terms. Maintainability, flexibility,...).
As usual, thanks for your help mates.
Well, the point is the next one. As web design do, using layout (relative and absolute) like div could be more complex at the beggining, but after the project is growing up, the benefits of using these approaches take relevance with the time.
If you need to change the style of the view, these layout are more flexible for doing it, just set the limits of the each element and you can add another element as well in a easy way.
But if you decided to use grid layout approach, and after, you need to change the style, the operation will be more complicated because you probably need to reset the definition of column and row for adding new elements and this implicate to recode every row and column for the other rows as well.
Hoping it helps when you are in design phase and you need to calculate risk and maintainability of your app.
Cheers mates...
Related
I have a big fat sort of table with lots of elements that make it really buggy.
For context 1 row per user, each user has X projects and each project has 3 month of day display (sort of gantt)
So I built something cool it's working great, but if I scale to more users it begin to be real buggy.
I'm implementing filter to display less users but at some point it need to handle the limit that I have now without being buggy.
What I found is when I'm updating a day it re-render the whole Gantt which is really stupid.
here is a minimal reproduction link: https://stackblitz.com/edit/vitejs-vite-g6azah?file=src%2FApp.vue&terminal=dev
As you can see when I'm updating an input with the v-model:
value.value
I have the attribute with the function
:test="testRerender()"
That trigger for the whole Gantt and I believe it is the issue here.
I saw v-memo that look like what I need but I can't figure out with the doc how can I use it to match my needs (and there is almost no good article on it)
Thanks for your help you would save my life!
I tried to filled proper :key attribute, code optimization, v-memo etc...
I have two xpath selectors that find exactly the same element, but I wonder which one is better from code, speed of execution, readability points of view etc.
First Xpath :
//*[#id="some_id"]/table/tbody/tr[td[contains(., "Stuff_01")]]//ancestor-or-self::td/input[#value="Stuff_02"]
Second Xpath:
//tr[td[#title="Stuff_01"]]//ancestor-or-self::td/input[#value="Stuff_02"]
The argument for example is that if the code of the page will be changed and for example some "tbody" will be moved that the first one won't work, is it true ?
So any way which variant of the code is better and why ?
I would appreciate an elaborate answer, because this is crucial to the workflow.
It is possible that neither XPath is ideal. Seeing the targeted HTML and a description of the selection goal would be needed to decide or to offer another alternative.
Also, as with all performance matters, measure first.
That said, performance is unlikely to matter, especially if you use an #id or other anchor point to hone in on a reduced subtree before further restraining the selection space.
For example, if there's only one elem with id of 1234 in the document, by using //elem[#id="1234"]/rest-of-xpath, you've eliminated the rest of the document as a performance/readability/robustness concern. As long as the subtree below elem is relatively tame (and it usually will be), you'll be fine regarding those concerns.
Also, yes, table//td is a fine way to abstract over whether tbody is present or not.
What is the best practice for having many different menus/screens/forms in a visual basic program? Would it be to just make a new form for each menu or screen that I want? Or are there other better options?
I am not trying to make this overly complicated, I have a group project to work on and we all have different skill levels. That said it has peaked my curiosity so I figured it wouldn't hurt to ask before I got started.
I can see this question being closed pretty quickly as being too open ended so allow me to get in my key gripe on this before that happens... no .Visible property for TabControl pages? Seriously, Microsoft??
Which brings me to the key point. If the forms are in some way related but not necessarily identical I prefer to use a single form with different tabs, despite that glaring shortcoming in the control. (Which you don't have to look far to find workarounds for on SO, but a workaround is still a workaround.) Dynamically manipulating controls at run time is another side of this coin, though one that I tend to use more rarely... but that's just a personal thing.
In a recent application, for instance, I had lists of several types of objects. They were related, but performed quite different functions and the user wouldn't really need to look at more than one list at once. As a result I used one form with a tab for each object list to keep the users' display less cluttered.
Similarly when doing a GL app recently I had the journal header and journal line entries (which go to different tables in the back-end database) in separate parts of the one form. On the other hand asset creation was sufficiently different that I created a different form, despite the creation process sharing some of the underlying data. (That is, journal line data.)
I don't believe in the concept of "best practice" because what's a good practice in one situation may be a very bad one in another. However the "rules of thumb" that I use are:
- Keep the number of forms to a minimum to keep overhead low and reduce maintenance BUT
- If there is no logical "tie" between two functions, don't be afraid to make a new form because trying to maintain one form which performs 7 different roles is a guaranteed path to madness and frustration, especially if you break something inadvertently.
Yes, the two rules conflict, but in a way I see this aspect of design as being akin to database normalisation; there's a sweet spot between over-normalising (a separate form for each and every display) and under-normalising (trying to shoe-horn too many unrelated functions into one form). At the very least the rules always give me pause to think "do I need this form, or does it relate to something that I've already done?"
And the third rule of thumb is, obviously... always look at it from the point of view of your user. Are they going to feel like you're bouncing them around too much? Do all of the forms share a look and feel and, more importantly, control layout so that they always know where to find something?
All of these things will vary from app to app, and there's never one size that will fit all IMHO.
In my case, when I am dealing with multiple forms, I use MDI Parent Form to avoid multiple items in the windows task bar.
Another unusual solution is to set each forms ShowInTaskbar property to false.
I'm interested in displaying 1-5 model instances using forms on a page using a grid similar to something one would find in a desktop database application. I understand I would need to use multiple forms or formsets but an additional requirement is that I'd prefer it to be in more of a grid format with each model's fields being display in columns with common field labels on the y-axis.
I should have the ability to edit multiple columns (so in effect, model instances) at the same time and then commit either the single column (model instance) or commit all. I'd also like to be able to highlight the changed cells that have changed to give visual feedback to the user that there are pending changes.
Sorry for the rather long list of requirements and I'm aware this probably requires a few different technologies/techniques to achieve. I'm throwing this out there because I'm asking this kind community for guidance on what components/technologies I should look at. If luck would have it, there would be some jQuery component that can handle this for me almost out of the box. If not, some guidance on achieving the editing of multiple model instances would be of help.
I will also need to build in versioning in case the data displayed on the view page is stale and to prevent overwriting a newer commit. I'd probably achieve the latter using a versioning field in the table that will perform the check and handle it accordingly.
Also, Flask and Django are both options for the engine and WTForms look to be promising at least at first look.
Thanks
There is no such ready to use solution in Django. Just create your custom form that handles as many instances as you want and do anything that you want, or extend formset.
I'm trying to figure out if it's possible to use different row templates for specific rows in an NSPredicateEditor (or, if need be, an NSRuleEditor). I've got a screenshot that I think helps me explain this more clearly.
In this contrived example, I only want people to generate a filter that looks for a specific path above a certain size. So, in Section A (the Any block), users can only specify path rules (and the users can add additional paths). In section B, I only want the Size option to be available.
Nothing's jumping out at me from the docs (or, the stuff that does jump out at me ends up being something else), but it seems like this is the sort of thing that might come in handy, which makes me think it might be possible.
From what I understand about NSPredicateEditor, this is not possible. You might be able to swing it if you do everything yourself with an NSRuleEditor, but I haven't played with that class as much.
So in a nutshell: if you implement it yourself, it's possible. With the built-in stuff, I'm 99.9% certain that it's not a configurable behavior.