I am currently getting my head around aspdotnetstorefront.
My initial thought is to build usercontrols or something else instead of xmlpackages for extending the functionality of aspdotnetstorefront. Is there a reason why I have to use the xmlpackages instead of something else?
There are a few reasons I would choose to use the XMLPackages. First, it is what the products use for layout, so it is easier to replace existing packages. ASPDNSF has built a bunch of functions for the XMLPackages to give you access to their core functionality. You can use the XMLPackages in topics and the templates, so no need to roll your own code. Finally, if you have simple html and javascript to return, it is nice to just use XSLT to do it. Yes, the learning curve is a bit steep, but depending on what you are doing, it makes life easier.
HTH
Wade
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'm looking for some guideline what's the difference between #fluent-ui/react and #fluent-ui/react-northstar. This documentation (READMEs) are super imprecise. I'm don't understand which one to use for what.
I'm writing that react-component to be ran in webapp and the word plugin. Do you know which one to go for? They both look a bit different and feels that theming works a bit different.
You should use fluent-ui/react-northstar if you want to develop apps for Microsoft Teams, else you should use the normal fluent-ui.
If you look at a simple example of a dropdown, you will see that there is quite a lot of difference between the two. Northstar's dropdown combines the features of the dropdown with combobox.
northstar:
https://fluentsite.z22.web.core.windows.net/0.51.4/components/dropdown
normal:
https://developer.microsoft.com/en-us/fluentui#/controls/web/dropdown
https://developer.microsoft.com/en-us/fluentui#/controls/web/combobox
Another to take into consideration is that Northstar's scope is limited to Web / Desktop at present.
https://fluentsite.z22.web.core.windows.net/0.51.4/faq
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.
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.
I'm using VB.net so keep that in mind.
I'm trying to create a program that is highly edible. Users will be able to change multiple things by just replacing the existing dlls. Kind of like a modding ability.
The new DLL shouldn't have to recreate every function though, it should only include the ones that it changes and then hook to the old dll for anything that it doesn't have. Is there a way to dynamically do this? Reference another dll (like a proxy) through yourself for anything that doesn't exist in its self?
Sorry if that is confusing. If it still confuses people, I'll draw a picture later =)
I'm Sorry, but it must be done this way. I have already set up everything in the manor and told clients (they have already started developing).
Sounds like you want to write a plugin architecture into your application, why re-invent the wheel, take a look at the Managed Extensibility Framework