I'm just starting out looking at Composite C1. I installed the Open Cph Starter site, and I've seen how to edit, navigate, etc.
Under Media Archive I created a new folder and added my images. Is there a way to direct the Bootstrap Carousel to cycle through the images in my new folder rather then the Sample Media folder?
Composite's available documentation is pretty thorough and helpful. I would highly recommend that you read through it all as it will give you a much better idea of how to best use the Composite CMS. It's a fantastic piece of software with amazing capabilities at customisation and extension, but without knowledge on these topics you may fall short on attempting implementations.
The specific piece of functionality you are targeting is called 'Functions' within Composite. The Carousel you are talking about is most likely implemented using a 'Function'. To change the target folder for the 'Function' you would have to open up the Composite Admin interface, edit your page, and then double click on the 'Carousel Function'. This should display a 'popup' function box editor, with which you can change the target folder selection.
Again this is the basic functionality of Composite described in their documentation. You can view the documentation for functions here: http://docs.composite.net/Functions
I would highly recommend that you read through all their basic user level documentation.
Related
I have created an website/application using Angular2. The infrastructure is all set, I have routing completed, sass being processed etc.
I have sections (components) on this website that will display current web standards for our designs (buttons, forms, copy). The purpose of this site is to give our developers a copy/paste solution for markup and sass.
We will most likely create our own css library but they will still need a good visual reference of what each class does and a copy/paste solution.
I know how to develop all the standards, what I don't know how to do is have the DOM display options for the user to copy/paste the code. I could manually enter the code into or tags but this will be hard to maintain and not very clean approach. I'd like to find some solution that will utilize my code and create these tags at run time.
Googling this question leads down the road of using living style guide generators, which i don't want to use... why? I like having the functionality of controlling my own layout and scaling my standards as I see fit with our own technology.
Any ideas?
After exploring this even further I ended circling yet again on documentation tools (KSS) where I would need to rebuild my entire style guide for this functionality using markdown and or JDOCs.
Solution!
Use CodePen, its free to signup however there are some nice to have features for a monthly fee. I easily created my code here using SASS, HTML and CSS libraries. CodePen has a great EMBED feature whereas I could copy/paste html or iframe right to my styleguide.
Problem is now solved, and we have have a dynamic Web & UI Styleguide.
Hope this method helps others in my situation.
I posted a question on the Drupal forum about whether I should build my database in Drupal using content-types or the database abstraction layer and schema module: [here][1]
Any advice would be greatly appreciated.
[1]: https://drupal.stackexchange.com/questions/98020/should-i-use-content-types-or-database-abstraction-layer
I'd recommend using content types.
For a PHP coder, sometimes using the Drupal User Interface to build things feels non-intuitive, but in the long run you're going to benefit a lot from doing things "the drupal way.
Once you reverse engineer your need into a content type and all it's associated fields, install the modules that provide those field types and set things up, you'll start to see the benefits.
Validation on all the data-entry froms will already be done for you.
Multiple display modes are available for your data (email addresses can be shown with or without mailto: links, images can be shown using any of Drupal's image styles)
Integration with other Drupal modules already exists, and will be supported (almost anything built with fields is available to views)
By writing your own schema you'll need to handle all these things yourself (and more), and not just once, but you'll need to maintain all that custom code over time.
Learn to leverage the community and all the great work that's been done already, you'll save yourself time in the long run :)
What i see you are going to have shop site.
You may tray this:
https://drupal.org/project/commerce_kickstart
, i've found it usefull once. It's drupal distribution with nice themed shop rady to use straight forward.
And of course do it with content type + views + entity reference modules.
Here is a link to a comment that answers the question I asked. It backs up what arpitr outlined in their answer on the orignal post on the drupal forum, whose answer is also in agreement with jenlampton's suggestion above.
https://drupal.org/comment/7848011#comment-7848011
I will implement my system using node entities until the need arises to build a custom entity (if it ever does).
The top answer in this forum give a good way to evaluate whether to use nodes or custom build an entity:
https://drupal.stackexchange.com/questions/22586/when-is-it-appropriate-to-create-an-entity-versus-just-adding-a-new-content-type
The question says it all really. If you are writing a WPF application, how are you integrating the application help? What is the state of play in mid-2013?
It seems that there is no clear answer to this from an afternoon with a search engine, but several options:
Write your own fancy tooltip based help (but where are you getting your data from?)
Use .CHM files and the Windows Forms help system (seems archaic to me).
Use Microsoft Help Viewer 1.X or Microsoft Help 2.0.
There is some confusion as to which is more recent / approved of by MS. It appear Help Viewer 1.X might be the recommended option over Microsoft Help 2.0. It doesn't help that the names are so similar...
What is the status of 2.0? Should we use it? Was it ever fully deployed?
Use a third-party product to author your help files and link to them somehow - DocToHelp/NetHelp, NetAdvantage on-line help, etc...
Furthermore, what XAML based mark-up / attributes are you using to provide the necessary context? What is the recommended method?
It seems surprising there is no clear path for supporting application based help in WPF.
My current preference is to use a third party help authorizing system to generate HTML based help.
We then use a WebBrowser to display this help as needed. The authoring system we use makes it fairly easy to extract out a single page from the main help (each "topic" is a single HTML file, and can be included with full contents or not as desired).
Granted, this definitely felt like a bit of a nasty hack at first - but once we wrote the basic plumbing (some attached properties for xaml to specify attributes for context location and add behavior to trigger help, etc), it's fairly clean.
One very nice advantage to this approach, however, is a single help system build works perfectly in all contexts - we can include the documentation online, expose it locally for use in a browser, and use it with context from within our application directly.
By good, I mean using hooks/filters.
Basically, by default the two options are Images and Uploaded to this page. I would like to add an additional option in there. I know how to add a new tab to the media manager (see here), but that doesn't achieve what I need.
I've been looking through the limited documentation on 3.5 and have found the media_view_strings/settings filters, but, based on what I can tell, neither could be used in this case. I've also done quite a bit of digging through the core source, but the number of files relating to the media uploader is daunting to say the least.
I thought about running JS after page load to modify the DOM and just add the extra select option in, but this seems very hackish and I'd like to avoid it if there is a better, more robust solution.
Any thoughts on the best way to approach this would be greatly appreciated!
Note: I didn't post this to the WordPress SE Site since it gets much less traffic and the questions tend to be much less programming-related.
Most of those select-dropdowns are from wp-includes/media-template.php, which has a lot of Underscore templating (<script type="text/html" tags), but few action hooks for php code. With Javascript you can bind the Backbone.js hooks for wp.media events, such as wp.media's open/close events. From such event you could grab that Images/uploaded-to-page selectbox with jQuery('.media-modal-content:visible .attachment-filters'), add item(s) and listeners as needed. I'm pretty sure there should be a much better Backbone.js-style solution, though.
Here is a tutorial by Shiba Shake on this subject ...
How to Expand the WordPress Media Manager Interface
Hope this is helpful to you!
I started a trial of Sencha Architect, and the more I use it more questions come to my mind for its actual feasibility usage in a development environment, one of the bigger questions I have is
In an environment that you can't edit the individual files in different editors, how can multiple people collaborate in developing different parts of a site, for example
app/models|components|views/Model1.js <- In charge of developer one
app/models|components|views/Model2.js <- In charge of developer two.
In a regular environment you could use git, for example, to distribute each file but in architect, you are not expected to edit files manually (which sucks because features like profiles are not exposed in architect). If you do edit them manually, it will cause problems or it may overwrite your code back to whatever data is on the project file so I am wondering what is the proper, or expected collaboration workflow with Sencha.
Having read the above posts, I still can't believe that keeping Sencha
metadata files in code repository and generating ALL JavaScript from metadata is suitable for big projects.
The idea of Sencha Architect is to keep the code not in javascript files, but in JSON metadata, and whenever you need to edit a JavaScript code, you have to use IDE and edit metadata. Phil Strong said "We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN.". Of course this workflow is very profitable for Sencha, it forces 20 people to use a licensed Sencha Architect, because to change a single line of JavaScript code the developer must use Sencha Architect.
When two people edit the same file, IDE updates metadata. Then they check-in the file into a code repository, and one of them has to resolve conflicts, so the developer has to merge two metadata files, not JavaScript files.
The whole idea of not letting developers to edit JavaScript unless they use Sencha Architect is counter-productive, because the same person can be using his favorite IDE for both Java and JavaScript development, or Python and JavaScript. Doing both client and server programming in the same IDE is faster than switch between two IDE's. The reality of a big project is that you have multiple teams around the globe who work with different IDE's, you also may have a short-term project implemented by a contractor who also has his favorite IDE.
ExtJS is a well designed framework, you don't need SenchaArchitect to modify a single line of JavaScript code.
When coding in JavaScript, I save my JavaScript file and refresh browser, and see the changes immediately. Sencha Archtect adds and additional step, it requires you to publish
javascript (generate JavaScript from metadata), and the bigger the project is, the longer is delay. Often I have to modify JavaScript files in production, sometimes changing a single line fixes the problem, again, I have to use Sencha Architect to re-generate this single line from metadata.
I use Sencha Architect for quick prototyping only, then check-in generated files into code repository and continue to edit JavaScript manually. With this approach I can use a version control system to see the history of JavaScript. If I checked in JSON metadata into
a VCS, then I would not have the history of JavaScript, I would have the history of JSON metadata which is counterintuitive.
I think that having metadata for GUI form is OK, but the limitation that MVC controller level has also to be generated from metadata is not OK.
While I appreciate very much Sencha's effort in creating useful and full-featured dev environment I don't think Sencha Architect is quite ready for relatively big projects and teams of developers.
I original Architect software very useful for quick prototyping and designing complex UI structures, but then again - after you figure out the way your UI elements will lay down in JS file - often it's easier and faster to copy-paste existing JS code.
I don't think this is the answer you were looking for, I just wanted to share my thoughts.
When I had searched for this same topic, I had found that it is the metadata/ directory that is the important meat of the project, and that all of the components are separated out into their own metadata files. This, along with the root level project files, is probably the important part for version control. The app/ is regenerated on save and probably can be excluded from version control.
The main xds project file containers more general references and will probably change less often than the metadata components. But it would change when new components are created or project/app level settings are modified.
Ideally, if you just check in the root files and the metadata folder, it should just work.
Working in a team with source/version control is quite easy with Sencha Architect. An Architect project is all enclosed in a project directory. Inside it's made up of n parts
project file - consists of a small amount of data used by Architect to open and maintain your project. It's the single file you can double click to open it
metadata directory - consists of the files that describe all the pieces of your project. Each class (controller, view, model, store, resource) has it's information stored in it's own file.
app directory - consists of the src of the project you've created. A javascript file for each class.
other root files - an app.html and app.js which is the launchpad for your application and what get's run when you preview your application. This is also where your packager.json, app.json would go.
The point of me describing all of this is to show you that the files generated by Architect are pretty much identical to what you would have created in your favorite editor by hand. The only additional information is the metadata and the project file. The metadata is all JSON.
FOR NOW!!
We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN. When a dev makes a change it changes both the metadata and the app for those files.
I asked the same question to Aaron from Sencha in a private message. He suggested to check in the entire project structure including app and metadata.
It works, we did one flow in our team.