I'm building my first vue.js app and I'd like to have some help on deciding a design approach.
This app is going to be embedded inside a page of a site - built with Drupal 8.
Both app and site are going to use bootstrap 4 as base framework and we're going to use sass to style.
It's a quite simple app: a multistep form with some ajax call done to the aforementioned site.
It has anyway some components - one for each step, for some of the more complex input, for a sidebar showing the result of the ajax calls and so on.
I need to decide the "guideline" for styling this app and I'd like to get some help\insight to what solution is better.
On one hand, I could put the style inside the app itself; on the other hand I could leave all the style to the one present on the site.
As far as I can see the benefits of the first approach are the use of scope of each module, thus having a better "modularity".
However, putting the style all inside the site would avoid code duplication - simple example: custom color variables.
Personally I can't see for now other differences right now.
I haven't found material about the suggested approach and the pros\cons.
Could advice me of which approach is the best? Thank you.
It depends on the project, but you can make a list of cons and pros based on your project brief. If there are very few (or 0) changes in the future or it's based only on small components (not much style) then go with component-scoped styling. If the project is big, always go with a style pattern like the 7-1 pattern
I prefer working with the 7-1 pattern pattern.
Pros:
- Scalability or future updates like you mentioned the color variables case.
- You don't depend on Javascript to load the style, depending on how you write the app or how it loads, it may have glitches.
Related
I am currently developing a web application. I am using Bootstrap-vue in frontend. Does Bootstrap has feature in which I can create on-the-fly class? Tailwind has it . I tried searching it in the internet but no luck.
Here is my case:
Color values are save in the database.
Every time the page loads, I will fetch those colors and create class based on their colors
Your help is much appreciated. Thanks in advance.
Bootstrap is not really an utility-based CSS framework, hence there is nothing similar to Tailwind because it's not the mindset of the tool.
Also, even if this kind of code exists in Tailwind, it can become funky pretty quick and the best thing is still to write some bare simple vanilla CSS code alongside your template to get what you want.
You won't get any performance benefit by using an arbitrary value anyway and hence it should be used for exceptional cases anyway, a CSS declaration will be far more cleaner.
Feel free to create global CSS variables in vanilla CSS for your use case.
I have a webpage that needs to be able to generate and later read barcodes. But i cannot seem to find any small scale addon to aurelia that does even one of these. Is there any libary that does this or do i have to write my own somehow? Or can i somehow use some preexisting barcode stuff that is not directly designed for aurelia?
looks like you have to find a suitable library for the task on npm.
For barcode generation, you can use this test app:
https://codesandbox.io/embed/barcodes-bxgf1
Be sure to adapt to your own bundling choice.
I used quaggaJS in my aurelia app for reading existing bar codes.
(it's actually just a regular JS package - not specially for aurelia)
the API is kind of old (callbacks instead of promises), and overall it's a little weird (the Initialization process), but in the end it works great with little effort.
you can use https://www.npmjs.com/package/qr-scanner only draw back is that your website need to be https.
We write a lot of intrasite modules and are noticing that they really deviate now in SF 4+ from the content-based ones. So, on that note, I have some questions:
How do you get the EXACT look and feel of the standard modules for the edit/create form? For example, how do you eliminate the menu above, center the form, etc, as in, say, the Events module?
How do you add an actions menu dropdown to a radgrid, same as you'd see in the grids for standard modules?
How do you incorporate Sitefinity fields into the usercontrols? For example sf:ImageField throws script errors when added to a control? Also, is there documentation on each of these fields and how to configure?
---finally---
If we really want that standardization, do we have to go with another module type?
4.Is there a module type that will allow us to access non-sitefinity data (ie separaate db
but also provide us with exactly the same functionality and UI experience as the content-
based modules?
intra site modules are simply custom user controls (ascx) placed into backend pages to add your custom functionality to the backend. To copy the look and feel of the rest of the site, I literally copy and paste the HTML into the control.
I did a webinar on this a while back, including code to recreate the backend editor. It appears to still be valid, and is available here: http://www.sitefinity.com/blogs/joshmorales/posts/josh-morales-blog/2011/06/30/sitefinity_intra-site_module_webinar_notes
the centered view is a bit different, and I don't have that html, but you could potentially do the same (copy it from another native page). I don't always get it 100% accurate (my controls are usually laid out different from what Sitefinity does) but I get close enough so that it doesn't break the user experience.
The actions menu could be recreated with javascript, but if you are looking for NATIVE integration that does all this for you, indeed you would be looking at inheriting or much better yet: simply using the module builder, which lets you build custom types that automatically install themselves into Sitefinity as if they were regular modules.
Fields are definitely designed to run inside the context of native sitefinity module definitions (the classes that make up the UI using the Sitefinity context). This doesn't mean you can't include Sitefinity content in your modules; it simply means if you do you'll have to implement the integration yourself using the API.
On your last question, the only way to use external data but still keep the "Sitefinity Content" UI is to inherit from Content, then create a custom provider that reads from your database and translates it into the Sitefinity content type. It is certainly possible, but is quite a big project.
Unless you are in full need of this tight integration, I recommend simply going intra-site, linking to Sitefinity content types,taxonomy, etc through the API and manage it separately.
I hope this was helpful!
We are trying to make an app maker with dijit. Do you know what to do more or less to have the dojox.mobile.* branch running parallel to my dijit app ?
I know there is a seperate dojox.mobile.parser,... I guess, I need to fork it quite deep ?
I thought first about an iFrame but we need drag'n drop from the designer and the simulator.
Any help is welcome,
g
dojox.mobile offers a very light-weight parser which can be used in place of the standard dojo.parser. I think it skips stuff like attachpoints and probably wouldn't work too well with Dijit, so if you use both types of widgets on your page, stick with dojo.parser. The parsers share some globals and are unable to co-exist, so do NOT load both.
We are in the middle of a relatively large project which uses ExtJS3 and have already invested ~4 man-years, using several plugins and we have written some plugins ourselfs. After a quick glance at ExtJS4, it seems that we would have a lot of work to do to migrate the project to ExtJS4. Are there any strong reasons to switch to ExtJS4? Currently, it seems to me that compatibility with future browsers (or the lack thereof) is the only one.
We're in similar situation and our conclusion was to wait a bit more as Ext 3 is doing it's job. We experienced many problems in our "test" migration and I would say that it's more a rewrite of the application than a migration :(. Also, our experience showed that Ext JS 4 has some performance problems, forms are a bit different, store cannot reject changes, it's bigger. There are some very good new features like the new class system, mixins, new charts, ...
We have upgraded our application to ExtJS4 without fail.We are happy to say that ExtJS4 is fast compare to ExtJS3.A new class system,mixins,plugin-free charts,focus management...etc.,. But if you want to upgrade you need to change a lot of code because class system and config options are changed.We have tested the performance of our application using ExtJS3 and ExtJS4,so as per our observation ExtJS4 is fast and it will not break.As per our observation,CSS selectors are also changed if you want to customize the component you can easily do the thing in ExtJS4.
We tried to migrate from ExtJS3 to ExtJS4 previous week. Unfortunately I must say it is like translate english to german. A lot of work. From our point of view more or less just the charting system is plus, minus - a lot of components that we use are not supported, a lot of css customization shoud be done, working code in ExtJS3 breaks easily and there is sometimes almost impossible to find an error.
Not an expert but personally I'd start new project with extjs4 but leave exiting project alone. The charting stuff is amazing in 4!