I have been working on polymer/designer off late. I wanted to mess around, add more components etc. I am still learning polymer and I need some help.
I need to know the difference between the components and the elements. I know what components are.
Clone this: https://github.com/Polymer/designer
Run it locally. I need to understand how the code works for this. Check the components and the elements folders. And also the index file. A simple explanation is to how it is all connected and rendered etc.
As far as I understand it components are the building blocks for elements. As you can see in the elements folder you need at least one component for your element. In general I think the term might be interchangeable since components have dependencies on other components as well so they are actually elements as well. I think you should worry too much about the terminology :)
Related
This is my first post on stack overflow so forgive me if I have made any mistakes around etiquette.
I have recently started working in REDCap and have an intermediate (or less) understanding of work with HTML/CSS. This, in hand with REDCap's lack of resources and counterintuitive design, has made things a bit difficult.
I am currently working to modify the color of alternating rows on a matrix. While other fields offer the option to edit source code, this is not the case with matrices. I have gone to work in the CSV to see if I can make edits to no avail.
My questions are:
Can these edits even be done?
Would these edits be made in the CSV, or elsewhere?
Are there any good general resources for learning about aesthetic design for REDCap surveys?
Thanks for the replies in advance, really appreciate it.
As to your last question, you would be best off speaking to your local administrators and they can put you in touch with other admins via the REDCap Consortium Community who have done a lot of custom work with modifying the survey design and aesthetics.
You will also need their assistance with my suggestions below, for your main question, since you will need some external modules to make these changes, and they can only be installed on your instance by an admin.
So, get the CSS Injector External Module and you can override the standard survey CSS with your own rules. This may be sufficient to do what you need, but if not – say, if the DOM doesn't contain sufficient classes or ids to select in your custom CSS – then you might want to explore the JavaScript Injector External Module, which you might then use to modify the DOM to include classes that you can then style with your custom CSS.
I have been developing a VueJS website for a few weeks, and realised my design skills were not good enough to design a proper landing page. I came across this stunning Bootstrap open source template and really would like to use it.
However, I would like to stick to VueJS since I need it for some other dynamic pages. What would be the best way to integrate this template into a VueJS component? It uses Bootstrap and a bit of JavaScript as well. I know of Vue Framework such as BootstrapVue, but they would require rewriting the whole page using its custom components (such as b-nav or b-nav-item).
I have tried just copying and pasting the HTML into a component but I then have the problem of the CSS and JavaScript. Is using a bootstrap.css file in Vue JS a good practice ?
I am not asking anyone to do some boring job for me, but it seems to me like tweaking such a template so that it fits to a VueJS component always has some side effects, and I wanted to make sure there were no easiest, more elegant and reliable solution for this.
The whole point of BootstrapVue is to drop Bootstrap's dependency on jQuery.
It only uses Bootstrap's scss and the jQuery part is replaced with BV's own JS (provided via Vue components).
At first glance, it doesn't look like that would be your case, since you want some additional jQuery code (the theme's own JS) - currently written in jQuery.
However, when looking closer, the theme's own jQuery script is quite small. It basically does three things:
routes the page URLs when you navigate between sections (which could/should be replaced by Vue Router calls in your case),
implements scrollSpy (which has a Vue alternative) - it does it for the same purpose - knowing when to change the page URL,
implements magnificPopup (which also has a Vue alternative).
So it looks like the jQuery dependency could be fairly easily dropped, provided it's replaced by Vue code.
You basically seem to want a Vue variant of the Bootstrap theme. Or, to be more exact, a BootstrapVue variant of it.
If we were to look for the best possible candidate for the job, it would probably be found somewhere in the pool of Vue or BootstrapVue experts, as well as the creators of the Bootstrap theme (chances are they shouldn't find BootstrapVue difficult to use - considering the quality of their template).
Whether or not this is a job fit for your abilities is a question only you can answer but, unless you're purely interested in the functional part (getting the job done[1]), it is definitely a good opportunity to learn more about both Vue and Bootstrap.
To provide a helpful estimate, a senior FE developer would take anywhere between 8 to 20 hrs to create this template, provided they know Vue.
[1] Getting the job done with the least amount of effort would mean to simply inject the entire template as a page into your existing Vue app, making sure you import everything it needs (jQuery, jQuery.easing, Bootstrap, magnificPopup & scrollSpy) - roughly estimated at ~4 hours - could be less but you have to account for testing and any potential bug fixing.
I strongly advise against this approach as it's likely to significantly increase the size of your app while reducing its scalability and flexibility. This approach produces applications nobody wants to touch as, in time, the probability that any modification will break some existing functionality increases exponentially.
Since SO questions are supposed to take no longer than 15 minutes to answer, it should be obvious none of the above described tasks is feasible as a Stack Overflow question. Besides, you need to show some of your own coding effort up so far and provide a minimal reproducible example.
I have a deep experience about WPF, XAML, etc. However, I'd need to create something in HTML/CSS/JS.
In WPF, but also in Silverlight, there is a very versatile element which is the "Grid". It's essentially a list hosting any kind of visual object, which will be arranged accordingly to the row/column collection definitions.
Here is a (simple IMHO) example for the non-xaml addicted:
http://wpftutorial.net/GridLayout.html
I believe it's the most important control for managing the layout of the visual.
Now, I'm wondering whether is there any equivalent "component" for the web world, possibly simple and clean: not tons of code for such a simple problem. In other words, I don't want to rely on frameworks such as ASP.Net, ExtJS or else. Just a guideline, with a minimal HTML/CSS/JS section.
It's fine relying on the most recent browsers.
Many thanks in advance.
Well, I found one by myself, although it's still under development: at the moment seems that only IE10 implements it.
http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_grid.htm
I really hope this feature won't be trashed in a short.
[This question is somewhat related to this question, but the answers are not...]
I have always used relative paths in HTML and scripting languages (PHP/ASP/JSP) to refer to EVERYTHING. I think the justification had to do with 'what if the website gets hosted in some weird subdirectory.' But my coworker has started throwing absolute paths into a PHP site we're working on. At first I was appalled, but then I thought, "why not? We'll never be hosted in a subdirectory." Nowadays, getting hosted in the root is not an uncommon necessity. Is it still necessary to "code" (markup, really) with relative paths? I think it's probably an antiquated practice by now.
Definitely. You never know where your code is going to end up, or for what purpose.
Suppose you build a new version of a site, but to help your users transition, you move the old version to a "/classic" subdirectory. The same often happens the other way around where sites will host a beta version of the new redesign in a "/new" directory.
Building it properly the first time shouldn't be a hassle, and you'll thank yourself for it one day.
Well, it's probably not the end of the world but it's building in a dependency that you don't need.
If for example you ever want to put a number of versions in subdirectories in a test harness, or subdirectories help to work around some other issue (such as combining this with some other app that insists on being in the root), you may find it harder.
Sure, you can probably always work around it in some other way - but the problem is you now have to.
Edit: Killed my opening paragraph as it was based on a miss-interpretation of the referenced article.
I always use an absolute path for the following reasons:
Includes:
1. When you use a templating system, you never know the directory structure that a document is going to have when it's calling the include.
2. If documents are going to be moved around, you can be pretty sure it's going to be the documents themselves rather than the includes. If it is the includes, then they're being moved my someone who knows what going on. Added to this, if it is someone not familiar with absolute/relative path, they'll understand absolute a lot better than relative.
css: (as well as the items above)
1. When editing with Web Developer, relative backgrounds disappear when your style sheet isn't in the same directory as the doc.
2. By spec, when you put something on the 'Net, it should be there for the duration. When I'm building something new, I build it in a new folder, or with a new file name and leave all the old docs alone.
If you're using dynamically-generated pages, dynamically generate your URLs. For example, with JSTL use <c:url>. Not only does this allow you to move your pages in the future, it also ensures that your URLs will be properly escaped (tell the truth: how often do you build query strings with &? if you want the W3C validator to accept them, you need to).
For my personal website, which uses PHP to build pages, I've created several methods: insertPageRef(), insertCodeRef(), and so on, that create valid HREFs. As a result, I don't hesitate to re-arrange my site structure as it evolves.
The case of being moved to a subdirectory is fairly unusual, I'd say. Far more usual is being hosted on different servers: you create your site for testing on "dev.yourcompany.com" then go live by moving it to "www.yourcompany.com". In that case, you need to use relative links for obvious reasons.
The Separation of Layout and Content is the domain of CSS and HTML - so far well understood. Now about separating...
I'm looking for hints and Best Practices to get started with the task of providing a "skin" or "theme" for a content management system.
Background:
We are starting to embrace a Portal Server/Content Management System and are starting to change the look and feel to match our needs.
Our designer has so far mainly worked with full control over HTML and CSS, tweaking either one in order to get pixelperfect layout. With adoption of the cms there's a lot precreated HTML (very semantic, almost no tables :) that needs to be skinned with CSS and Images. Though it is possible to change the HTML fragments, I'd prefer to do so only as a last resort.
As this provides the challenge of "how to get started" my question is about any tipps how to proceed or articles that can help managing or organizing this task - e.g. best practices in designing, how to slice this task or what tool to use.
It seems bad practice to just save a dynamically generated page to disk and make changes locally. This would be somewhat ok for the CSS files but changes to HTML elements must be retrofitted to the fragments that they are generated from. I'd like to keep this out of the designer's realm if possible. Also, the thought of Dreamweaver (or any similar tool) making implicit tweaks to the HTML structure is frightening for me.
For the curious: The mentioned CMS/Portalserver is Liferay, but the question is really language- and tool-agnostic.
Edit: FireBug (as Josh suggested) is awesome for trying on-the-fly changes to css. Is there more - either in the area of tools or in-process and self-organization?
If you're looking for practical examples of separating style and content, then I'd suggestion the CSS Zen Garden. Trawling through the HTML and CSS is inspirational and enlightening and should help with what you're trying to do.
My #1 tip would be be to make everything as semantic as possible and use lots of classes and ids to hook your styles onto.
Usually, Whenever I am in a situation Like this, I bring up the page in FireFox, inspect the different elements using FireBug and see exactly what css is applied to them. THen I'l just modify the existing css until I get what I like. You can even play around in firebug and modify the CSS without "saving" those changes.
Have look at CSS Tidy, we normally use this to clean up the CSS and reorganise for development and production. However, I personally prefer writing HTML/CSS by hand before using this. It is just a matter of individual preference I guess.