Hey so I'm finding the documentation around building dojo a little hazy around layers.
For my Dojo 1.7+ application I would like a layer that contains only Dojo, and a layer that only contains my code, so I can place the appropriate copyright/license headers at the top.
Looking at build profile template, I see:
layers : {
"dojo/dojo":{
include:["dojo/dojo","dojo/i18n","dojo/ready","dojo/domReady"]
},
"myapp/core":{
include:["myapp/core/module1","myapp/core/module2","myapp/core/module3"],
exclude:["dojo/dojo"]
}
}
But when I look inside my 'myapp/core' layer js file I see lots of occurrences of
'define("dojo*'.
I started tackling this by finding each occurrence of the dojo define and putting that in the dojo/dojo layer include list, but that doesn't seem like the appropriate way of doing layers, is it? At the very least can't I just include certain packages? Am I making a big misunderstanding here?
Bonus it seems like the layer property 'copyrightFile' no longer works. Has that been deprecated, or changed?
Thanks
Are all these ("dojo/i18n","dojo/ready","dojo/domReady") dependencies the only dependencies that your external modules need? If myapp/core/module2 requires a dojo module that is not included in the dojo core layer, then it will be included in the myapp/core layer.
I have gone down the path you are going found it difficult to maintain the separation of code over time. I would create a single layer with both dojo and your code.
Use a layer to encapsulate code that is for specific area of functionality. For example, I have a graphical workflow editor that has it's own layer because it includes a bunch of svg code that doesn't need to be present in the rest of the application.
Related
If I used both of them, could I run into conflicts? Is this a good approach to use?
It is possible and the MUI team has been resolved it.
From the documentation:
If you are used to Tailwind CSS and want to use it together with the MUI components, you can start by cloning the Tailwind CSS example project. If you use a different framework or already have set up your project.
It is necessary to Remove Tailwind's base directive in favor of the CssBaseline component provided by #mui/material and fix the CSS injection order.
You can read how: https://mui.com/guides/interoperability/#tailwind-css
Yes you can run both ui framework. But it is not a good approach. Every ui framework has the complete solution for designing ui part. Like in tailwind css you can have the JIT compiler for compilation your custom css. Or the other hand MUI has also.
I think you can go through just only on ui framework. I have suggestion for ui. For your next js project you can use-
Tailwind Css
Theme-ui
Thank you.
Definitely, You will be in a big problem because once you initialize a styling library it applies its basic styles to the components so that if you are using more than one styling library you may not be able to change the behavior or styles of the components.
It also leads to rubbish suggestions while adding classes names and so on.
Stick to a UI libray and go with it.If you cant get it using the ui libraray do it yourself using CSS that could be more interesting and you can have more control over the components.
Use Mui base instead of Mui core.
https://mui.com/base/guides/working-with-tailwind-css/
I have tried using Mui and Tailwindcss together and it's not worth it. First, you will have to use Mui/base instead of Mui/material in order to reduce conflicts check https://mui.com/base/guides/working-with-tailwind-css. And if you really need to customize Mui components styled of the sx prop. This is just my opinion.
I have an SVG asset of a map, in which I have to change the color of some cities depending on the results of a network call. On the web, one normally would add a class to each path, give it some CSS, and toggle that class using JavaScript.
How can I achieve the same effect in flutter?
This can be done with the new version of jovial_svg. It supports embedded stylesheets, so you can use CSS exactly as suggested. Of course, you'd need to re-parse the SVG whenever there's a change, but that's not a big deal here.
Alternately, if it's just one set of cities, you could use SVG's currentColor, and set that value in the appropriate ScalableImage factory. But for your use case, CSS seems like the better way to go.
NOTE: At this exact moment, CSS support is in pre-release, but it should be formally released as 1.1.4 within a couple of days. In the meantime, see https://pub.dev/packages/jovial_svg/versions/1.1.4-rc.3
I've been asked to create a CQ5 "overlay" component by simply copying the out-of-box component from /libs/foundation/components/flash to /apps/myproject/components/flash. My question is: what happens to the original - is it just ignored?
a CQ5 "overlay" leverages sling rules for resource resolving. if /libs/foundation/components/flash needs an overlay, you "overlay" the corresponding file at location /apps/foundation/components/flash/filename This will CHANGE how the foundation component behaves in all instances. And the existing sidekick component remains, but behaves differently.
If you have a NEW component at /apps/myproject/components/flash, it can inherit from the foundation component via sling:resourceSuperType on the new component. In that case, you have a new component in the sidekick. In your new component, you could use the same values for jcr:title, componentGroup, or you could change them to distinguish your component in the sidekick. If the title, componentGroups are the same, the sidekick can distinguish them with parenthesis around the webapp (foundation) vs (myproject). However, I have seen situations where it is impossible as an author to distinguish them.
It is not ignored. Both components can show up in the authors' sidekick -- one will say flash (foundation), the other flash (myproject). When one of these is used by an author CQ will instantiate appropriately. The usual rules apply for what shows up in the sidekick (group name, selected in design mode, etc.)
Just to clarify: overlay and flash are two different things.
Sample of overlay implementation: http://jquerytools.org/documentation/overlay/index.html
So if you were asked to create an Overlay component, copying a Flash one might not be the best idea.
I have learned that in iOS 5, properties that are marked with UI_APPEARANCE_SELECTOR can be styled using appearance. Eg [[UINavigationBar appearance] setTintColor:....]. However, I seem not to be able to style all elements. UIButton, for instance, has no properties marked UI_APPEARANCE_SELECTOR, hence I am not able to use the above technique to style it.
My question is: How do I best style elements globally (all appearances in the application), when I cannot use appearance?
Right now I have defined some colors, fonts, shadow offsets etc. that I use many different places in my code. This allows me to change the look and behaviour of a lot of elements, but it still doesn't allow me to style all instances of a certain object with only one line of code.
Edit
In lack of better solutions I have created a number of categories with simple methods as the following:
+ (UIButton *)customLabelWithFrame:(CGRect)frame andText:(NSString *)text;
Also I have found that - in combination with the described categories - stretchable images are nice and useful.
With the above I am able to style in a global-ish manner, however I am not satisfied with the result and I still hope to find a better solution
What about standard subclassing or factory classes, as you mentioned yourself!?
For buttons I'm using factory classes myself.
I think a really nice solution could be the Android way of designing interfaces. Android relies on XML files to define the user interface. As a matter of fact, I'm working on a library that aims to give the projects I'm working on much the same capabilities. It's still a work in progress / experiment and as such really messy code (you have been warned!), but it might give you some ideas.
An example project can be downloaded here: http://dl.dropbox.com/u/6487838/WSLayoutManager.zip
Experiment a bit with the XML files by adding controls. Create custom control classes and instantiate them from the XML file, etc... It's fun stuff :)
I just want to know if this is the proper way to go about splitting up widgets in GWT that get too large, or if I am missing the concept of widgets/proper GWT usage all together.
I started out with a single class (widget), PCBuilder. As PCBuilder became too large, I decided to branch off and make two classes SuggestionPanel, and BuildControlPanel, both of which just split off PCBuilder's code into separate classes that still have access to the methods in PCBuilder:
This way, in my PCBuilder class, I can do something like this to add the SuggestionPanel and the BuildControlPanel to the tabs (TabLayoutPanel) that are specified in the UiBinder of PCBuilder while allowing for SuggestionPanel and BuildControlPanel to have their own separate UiBinder specifications:
My question is: Is this proper? Part of me thinks "no" just because it's not a nice way of doing it. On the other hand it works just fine, and my web application is somewhat broken up into manageable "sections" which is what I wanted.
Thanks for any insight.
It's fine apart from the fact that you have circular dependencies between classes.
Why do SuggestionPanel and BuildControlPanel need to call PCBuilder? Is there any business logic in it? RPC maybe? Separate that into another class.
First, you might want to take a look at GIN - this handles dependency injection. This is good for testability.
Second, if your app goes beyond one "page", then take a look at GWT MVP.
You should not consider your PCBuilder as a widget. Quoting gwt -
You construct user interfaces in GWT applications using widgets that are contained within panels. Widgets allow you to interact with the user. Panels control the placement of user interface elements on the page.
Coming back to your question, my take is to create widgets only if I can reuse the same element more than once. The rest of my layout logic goes into the view. Layout shouldn't be a part of the definition of the widget as much as possible.To conclude, push styling in css, push layout in the views; widgetize only if re-usable (and core) or if adding additional functionality to existing widgets.