I was just looking into referencing css files in a theme, that reside in a different database and I was wondering:
Could I reference a whole theme that resides in a different database as well with "extend"?
The reason behind that is: Would it possible to keep themes in one central database that can be used by all kinds of applications and therefore, if there should ever be changes to the themes, they only have to be changed in one location and not in every application.
Thank you for your responses in advance.
no I don't think this is possible (happy to be wrong if someone else knows it is?)
to keep all your theme files in a central spot, an XspLibrary in an OSGi plugin is a good solution, however it is a steep learning curve if you haven't done this before. The benefit is once you know this technique it opens the door for 'centralizing' other parts of xpages.
you deploy the plugin to each server and each client if using xpinc, and the every nsf can use a theme from that plugin.
there are a few 'getting started with xpages plugins' articles popping up around. check through planetlotus.org (I'll edit this answer later with some links)
once you know how to do an XspLibrary, you can then download the source code of the bootstrap4xpages project on OpenNTF to see how they are serving up their theme from a plugin.
it relies on the Extension library though so if you don't use the exit lib you could reverse engineer the necessary parts of that project too!
this bootstrap project was set up by Phillipe Riand who was the chief architect of XPages, so it should be a good example!
I am halfway through creating a video series on doing a theme from a plugin but have temporarily lost motivation :(. I might finish it sometime this year, if I do I will post a link to it on this answer. in the meantime I am happy to answer any questions you have about it if you want to give it a go.
otherwise, a quick and dirty solution would be put the theme files / CSS / images directly on the file system of the domino server, where the other theme files are. 'Mastering XPages' might have some advice about this but I don't have it with me right now :)
I think the short answer is you won't be able to load just a theme from a different database.
Each NSF has it's own JVM, sitting on top of the server JVM. So you can extend a theme that's sitting on the server, but not one in another NSF.
XPages Single Copy Design loads a theme from a different NSF by effectively loading the template's JVM. So it's the theme, but also all other design elements.
Jesse Gallagher's done some work in OpenNTF Domino API to allow you to load an XPage or Custom Control from another database, but I'm not sure if that would work for a theme.
If you want to design once and use in many, you can add the theme to the server itself. Looks for the OneUI elements to see where you need to store it (or it may be mentioned in Mastering XPages). You can only nest themes to five levels, but you should be fine.
Related
i couldn't find any information on google for this so i thought i will just ask this general question.
we are developing a web app for customers who can change colors, fonts and stuff in their account through a simplified CustomDesigner (the name) Tab where they can pick colors from a color picker and fonts from a select-box and all this stuff.
currently all these dynamic changes are written through PHP in the CSS but we are working on a complete redesign and rework of the app and want to use the power of SASS for this.
my question is: is it possible to run ruby on a debian server and everytime a user changes some preferences in their account that ruby will compile the generated sass file or the "changed" variables into a new css file completely automatically?
if yes: how? i couldn't find anything at all about this topic.
if my using-example is not good enough and you can't imagine what i want:
think about the custom-bootstrap-builder, where you can simply change all the stuff from viewport-grid-size, fonts, font-sizes, border-radius and all that kind of stuff, and if you click on "download" it delivers a complete bootstrap version with your preselected preferences and downloads it completely automatically.
the download for my use-case is not necessary, instead i want the server to store that "compiled" file in a specific directory on the server and of course import it to the generated HTML.
after some more research and investing more time i found some "module" for nginx which is capable of processing less/sass/scss server side with nginx/LUA
https://github.com/titpetric/nginx-lesscss
i also found a PHP variant to use
https://github.com/leafo/scssphp/
i couldn't try any of these two, but it looks quite promising and i wanted to share if someone else has the same problem.
A friend has asked me to do some work on his existing site which was built in Rapidweaver. I'm on Windows, so is there another way I can access and edit his site?
The Rapidweaver project file is meant to be edited only in Rapidweaver, really. As far as I know, the only way around would be to use an HTML editor to modify the pages that are already in the server. However, I would not reccomend you to do it unless you are not going back to Rapidweaver anymore. Because changing the files in the server does not update your local Rapidweaver files. So, you could end up editing something in the server, then getting back to Rapidweaver and upload a "new" version that would not be completely up to date (the previous changes in the server version would be overriden by the older rapidweaver project).
For that kind of work, a CMS (Content Management System) is a more flexible way to work. Nowadays, one of the most common is Wordpress. It will require an inicial setup but after it is working it can be updated from anywhere via web browser, or even from an app in your iPhone. But it is not a Rapidweaver based sollution.
There are a couple CMS related plugins or stacks (Dropkick CMS, Armadillo, Easy CMS, Total CMS...) for Rapidweaver that could also be useful in this context. Once again, first you would need to buy a licence and to setup the website using one of those plugins or stacks. Only then you would be able to edit on the go.
I'm curious how other people have approached this. Our group has been given the directive of implementing an internal website utilizing Joomla. We've set up a dev server for the person who is responsible for maintaining the site, and a production server. We're using IIS and the current version of Joomla.
I can sync the two with Akeeba Backup Core and Kickstart, but it seems an "All-or-Nothing" choice. It works, but if she's doing work on, for example, the look and feel of the site, but just wants to sync content, that doesn't appear to be doable.
I feel that someone out there must have tackled this goal before, but web searches seem to turn up people running dev/prod on the same server but in different subdirectories, or ignore the "all-or-nothing"ness of the issue, going for the "Do all at once" approach, which doesn't seem practical. Content changes frequently, but not-so the look/feel.
We've been doing this for several years now. We use a dev server and a prod server. When we make content changes on dev, we use phpMyAdmin to copy the content table from the dev db to the prod db. In some respects, it's still an all-or-nothing approach, because we have to copy the entire content table at once. This means you can't have some pages still in development when you do the copy. In other respects, it still a piecemeal approach, because we can copy individual tables such as modules, menus, etc. But again, it's ALL modules at once, ALL menus at once, etc. There is a way in phpMyAdmin to copy an individual page or item from a table in dev and put it in the corresponding table in prod, but it's a little cumbersome. It works, though.
As for design elements (images, css, template changes, etc.) we do the same thing, but the copying is done manually by ftp from one server to the other. Obviously this is the same method for things like pdf files on dev that need moved to prod.
In summary, this method has worked fairly well for us for a long time. But it's limitation is that you must realize you're copying an entire table at once.
The positive of all of this is that when we have pages that are in development, I have leverage over the content people to hurry and finish their work because one unfinished page can hold up the entire site!
This workflow dilemma has come up a few times for me.
You mention changes to look and feel, and that is simpler really, if it is just template changes. It is quite simpler to pull down an Akeeba Backup of the live server, kickstart it onto a local server, work on the template files, and then upload the updated template files to the live server.
That said, if it is more than CSS and HTML tweaks to existing files, it can be a more involved process.
Personally I've not found a silver bullet for this sort of thing, but with some forethought and planning it is not too bad.
For about 12 years I've been working on a couple different web sites in Dreamweaver or even wayback in Homesite. That said, I've gotten very comfortable with the traditional set up of URLS with definite structures where you can logically follow the directory set-up and it was very clear how to program the relative/absolute links and more. I would either FTP the files through in Dreamweaver or would use some kind of Management Console. Recently I took a new job to help on a web site that currently lives and was built using Joomla. I'm looking to see if there is a way to get this entire site on my Hard Drive so I can work on it locally and then upload as pages are finished, or at the very least find out how best to work with this site.
Joomla has many things about starting a page from scratch, but I'm really trying my best to investigate a site that's already developed and find ways to make the necessary adjustments and take inventory of everything that's on the site. Any help would be much appreciated.
Thanks.
In order to administer a site in Joomla, there is no need to have any files locally. You can add, edit, and delete pages all through the administrative back end of the website. The entire site is built based on the query string of the URL. The string determines which component is displaying the content and which content to display.
There is really only one page in a Joomla site, the index.php file in the current template directory. Every page is built using that page. The only time you would need to modify that page is when there is a structural change in the site. Even then, if the template is well coded it should have various module positions available for use that collapse when they are not in use. This allows you to have a 3 column layout on one page and a 2 column layout on another simply by adjusting which modules display on a particular page.
I would highly recommend reading some tutorials before messing around with editing any files. Here are a few decent resources:
http://www.virtuosimedia.com/dev/php/joomla-administration-explained-a-joomla-15-admin-tutorial
http://www.joomlashack.com/tutorials
http://docs.joomla.org/Beginners
Part of the purpose of Joomla is to be able to manage the content of a website without requiring local copies of all the pages. So what you are asking sort of defeats the purpose of using Joomla in the first place. To do what you ask you would have to get an offline copy of the entire website, uninstall Joomla, and then upload your "static" copy. I would predict that the end result would be a web site that is very hard to maintain.
If you really really want to do this you could use a website copy tool like HTTrack. It supposed to be used to copy a website so you can browse offline, but the end result is what you are looking for: a local copy of the website.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.