Using .ai (adobe illustrator) variables with Drupal variables - drupal

As we know that we can assign the variables to Adobe illustrator file. Is it possible to access these variables by using Drupal 7 variables feature?

Short answer: no.
Longer answer: This is theoretically possible, but.
What you're referring to really amounts to rewriting some of the fundamental underpinnings of the internet. This would require, at minimum, extremely innovative development and entirely recreating several major software components. For example:
1) Users' browsers read and render hypertext. They would need to be rewritten to understand AI equivalents of links, pages, and other internet standards.
2) Javacript, Jquery, and other client-side components would need to be rebuilt from scratch. You would also need to invent a new CSS and DOM that their replacements can understand.
3) Apache .... would be mostly okay with some minor tweaks. One or two new extensions at most.
4) PHP (which stands for "PHP hypertext preprocessor" and not "PHP advanced graphical tool") would need to be entirely redone, along with all of it's extensions, integrations, and fundamental concepts.
5) Drupal and all its modules (which are build on the assumption that the output will be hypertext) would need to be substantially retooled. In particular, you would need a replacement for PHPTemplate that accesses AI objects.
So: There's a lot to do. I would say "let's get started," except that 6) AI is a proprietary product and we don't have licenses to develop and extend it.

I think it depends on what you want to do with the resulting file. Are you thinking of a variable data Illustrator document that would be generated from the values in Drupal? If so, I think that is very possible. The Illustrator file format specification is somewhat available, you would just need to process the file without the help of Illustrator (which may present some challenges).
If you want to generate something that would be viewable in a browser you're better off using SVG with some sort of placeholder that you could replace with regular expressions or maybe some XPath queries to get the nodes you want to manipulate and then adding your values there.
As Dominic said, the end use isn't very clear here so the answers are really dependent on what you need to accomplish.

Related

Documentation Generation - What boxes should I aim to tick?

I'm looking at requiring my team to document their code more thoroughly for some major upcoming projects and to make life a little less painful, I am steering towards XML documentation generators such as Sandcastle, Doxygen or Box Live Documenter.
What are the key considerations I should keep in mind when evaluating the best option and what experiences have led you to a particular decision?
For me the key considerations would be:
Fully automated: Can it be set up in such a way so that pretty much
no outside work is required to
create or edit the documentation.
Fully styled: Can the documentation be fully styled so
that it looks great in a wiki or pdf
after it’s generated. I should be
able to change colors, font sizes,
layouts, etc.
Good Filtering: Can I select only the items I want to be
generated. I should be able to
filter the namespaces, file types,
classes, etc.
Customization: Can I include headers, footers, custom elements,
etc.
I found Doxygen could do all of this. Our workflow is as follows:
Developer makes a change to the code
They update the documentation tags right above the code they just changed
We click a generate button
Doxygen will then extract all the XML documentation from the code, filter it to only include the classes and methods we want, and apply the CSS styling we’ve pre-made for it. Our end result is an internal wiki that looks the way we want, and doesn’t require editing.
Extra: We have all our projects in various git repositories. We pull all these down to one root folder and generate the docs form this root folder..
Would be interested to know how others are automating even further..?
Who is paying for the documentation and why? (is the system stable enough, does it add enough value)
Who is going to read it, and why is she not using a more effective communication channel?
(if correct mostly distance in time/place)
Who is going to keep it up to date.
When are you going to destroy it? (Automatically if it hasn't been read or updated in the past three months?)
I mostly prefer better code to make my life less painful, over more documentation, but I like scenario & unit tests and a high level architecture description.
[edit] Documentation costs time and money to write and keep up to date. JavaDoc style documentation has a serious detrimental effect on the amount of code simultaneously visible and might be a good idea for the developers using the code, but not for those writing it.

Is there a better .NET template system than XSLT?

I am creating a web application that will need to send a variety of emails out to users. Instead of hard-coding the contents of the email in the app, I want to use a template stored on disk and replace tokens in it (ex. "Hello, %%FirstName%%!") with the actual data. I have some experience with creating XSLT templates, but since the data isn't naturally in XML format this may not be the best fit. Is there a better template tool in .NET?
Note that I prefer one built in to the language but I'd consider add-ons too.
Thanks,
Graham
I have personally use Spark. Its an easy to use text templating library (below is an example of Spark syntax)
<var names="new [] {'alpha', 'beta', 'gamma'}"/>
<for each="var name in names">
<test if="name == 'beta'">
<p>beta is my favorite.</p>
<else/>
<p>${name} is okay too I suppose.
</test>
</for>
It even comes with a sample code for email text templating which you could look at on github.
You may want to take a look at MVCContrib. They have an e-mail template system IEmailTemplateService that uses Views to render the actual e-mail message which gives you access to a lot of features, including different view engines. If you are not in an MVC environment, you could possibly still extract some useful tricks out there.
I am using NVelocity for that, and I find it's very flexible and easy to use. It not only allows you to replace tokes, but it also includes sort of a programming language, e.g. for conditionals (if) and loops (for, foreach).
The original project seems to be dead, but there is a fork maintained by the Castle project.
Of course there are lots of other, alternative template libraries (stringtemplate seems to be popular), as you can see in this question I asked some time ago.

Comparing and rationalizing CSS - not file or diff based

I'm in the process of taking a couple of separate asp.net applications, and combining them.
One problem is rationalizing the CSS between the two app - app1 has two css files, while app2 has about 8 of them. Much of the CSS between the two apps is the same, but there are some differences. I'm looking for a tool to compare all the elements of each app, and show what's missing, what's different, etc. Ideally the output would be 3 files: Common, app1 and app2, but I won't be that fussy if it can just show me the differences between the two apps.
Does such a tool exist?
If you hate downloading tools, there's an online version of css comparer here http://www.alanhart.co.uk/tools/compare-css.php
It provides a comparison of css class files between two files
I don't know of a stand-alone tool tailored for this specific purpose. There's a PHP class called "CSS Comparer", but I have no idea how easy it is to use. The screenshot on that page looks promising though.
Personally, I would probably just concatenate all the files together, so that you have one file for each app, and then run a diff on them. To make it even easier, you could run both files through something like CSSTidy or do some imaginative file processing with search/replace and sorting. That could get all the declarations in the same order in both files, so the diff would be clearer.
Combine all of these files into a single file and give it a run through a CSS optimizer or compressor. An optimizer should see all of your duplicate selectors and weed them out.
I'd recommend YUI's compressor, but there are plenty of web-based compressors/optimizers available, too. Here's one and another. YMMV with them, but a good Google search can turn up a bunch more.
Normally I'd recommend diff. Since you explicitly write that you are looking for something "not diff based", maybe you could describe why diff does not help you.
Then others might be able to propose something different.

How do you use Excel server-side?

A client wants to "Web-enable" a spreadsheet calculation -- the user to specify the values of certain cells, then show them the resulting values in other cells.
(They do NOT want to show the user a "spreadsheet-like" interface. This is not a UI question.)
They have a huge spreadsheet with lots of calculations over many, many sheets. But, in the end, only two things matter -- (1) you put numbers in a couple cells on one sheet, and (2) you get corresponding numbers off a couple cells in another sheet. The rest of it is a black box.
I want to present a UI to the user to enter the numbers they want, then I'd like to programatically open the Excel file, set the numbers, tell it to re-calc, and read the result out.
Is this possible/advisable? Is there a commercial component that makes this easier? Are their pitfalls I'm not considering?
(I know I can use Office Automation to do this, but I know it's not recommended to do that server-side, since it tries to run in the context of a user, etc.)
A lot of people are saying I need to recreate the formulas in code. However, this would be staggeringly complex.
It is possible, but not advisable (and officially unsupported).
You can interact with Excel through COM or the .NET Primary Interop Assemblies, but this is meant to be a client-side process.
On the server side, no display or desktop is available and any unexpected dialog boxes (for example) will make your web app hang – your app will behave flaky.
Also, attaching an Excel process to each request isn't exactly a low-resource approach.
Working out the black box and re-implementing it in a proper programming language is clearly the better (as in "more reliable and faster") option.
Related reading: KB257757: Considerations for server-side Automation of Office
You definitely don't want to be using interop on the server side, it's bad enough using it as a kludge on the client side.
I can see two options:
Figure out the spreadsheet logic. This may benefit you in the long term by making the business logic a known quantity, and in the short term you may find that there are actually bugs in the spreadsheet (I have encountered tons of monster spreadsheets used for years that turn out to have simple bugs in them - everyone just assumed the answers must be right)
Evaluate SpreadSheetGear.NET, which is basically a replacement for interop that does it all without Excel (it replicates a huge chunk of Excel's non-visual logic and IO in .NET)
Although this is certainly possible using ASP.NET, it's very inadvisable. It's un-scalable and prone to concurrency errors.
Your best bet is to analyze the spreadsheet calculations and duplicate them. Now, granted, your business is not going to like the time it takes to do this, but it will (presumably) give them a more usable system.
Alternatively, you can simply serve up the spreadsheet to users from your website, in which case you do almost nothing.
Edit: If your stakeholders really insist on using Excel server-side, I suggest you take a good hard look at Excel Services as #John Saunders suggests. It may not get you everything you want, but it'll get you quite a bit, and should solve some of the issues you'll end up with trying to do it server-side with ASP.NET.
That's not to say that it's a panacea; your mileage will certainly vary. And Sharepoint isn't exactly cheap to buy or maintain. In fact, short-term costs could easily be dwarfed by long-term costs if you go the Sharepoint route--but it might the best option to fit a requirement.
I still suggest you push back in favor of coding all of your logic in a separate .NET module. That way you can use it both server-side and client-side. Excel can easily pass calculations to a COM object, and you can very easily publish your .NET library as COM objects. In the end, you'd have a much more maintainable and usable architecture.
Neglecting the discussion whether it makes sense to manipulate an excel sheet on the server-side, one way to perform this would probably look like adopting the
Microsoft.Office.Interop.Excel.dll
Using this library, you can tell Excel to open a Spreadsheet, change and read the contents from .NET. I have used the library in a WinForm application, and I guess that it can also be used from ASP.NET.
Still, consider the concurrency problems already mentioned... However, if the sheet is accessed unfrequently, why not...
The simplest way to do this might be to:
Upload the Excel workbook to Google Docs -- this is very clean, in my experience
Use the Google Spreadsheets Data API to update the data and return the numbers.
Here's a link to get you started on this, if you want to go that direction:
http://code.google.com/apis/spreadsheets/overview.html
Let me be more adamant than others have been: do not use Excel server-side. It is intended to be used as a desktop application, meaning it is not intended to be used from random different threads, possibly multiple threads at a time. You're better off writing your own spreadsheet than trying to use Excel (or any other Office desktop product) form a server.
This is one of the reasons that Excel Services exists. A quick search on MSDN turned up this link: http://blogs.msdn.com/excel/archive/category/11361.aspx. That's a category list, so contains a list of blog posts on the subject. See also Microsoft.Office.Excel.Server.WebServices Namespace.
It sounds like you're talking that the user has the spreadsheet open on their local system, and you want a web site to manipulate that local spreadsheet?
If that's the case, you can't really do that. Even Office automation won't help, unless you want to require them to upload the sheet to the server and download a new altered version.
What you can do is create a web service to do the calculations and add some vba or vsto code to the Excel sheet to talk to that service.

Storing content in multiple languages? E.g. English, French, German

How should I store (and present) the text on a website intended for worldwide use, with several languages? The content is mostly in the form of 500+ word articles, although I will need to translate tiny snippets of text on each page too (such as "print this article" or "back to menu").
I know there are several CMS packages that handle multiple languages, but I have to integrate with our existing ASP systems too, so I am ignoring such solutions.
One concern I have is that Google should be able to find the pages, even for foreign users. I am less concerned about issues with processing dates and currencies.
I worry that, left to my own devices, I will invent a way of doing this which work, but eventually lead to disaster! I want to know what professional solutions you have actually used on real projects, not untried ideas! Thanks very much.
I looked at RESX files, but felt they were unsuitable for all but the most trivial translation solutions (I will elaborate if anyone wants to know).
Google will help me with translating the text, but not storing/presenting it.
Has anyone worked on a multi-language project that relied on their own code for presentation?
Any thoughts on serving up content in the following ways, and which is best?
http://www.website.com/text/view.asp?id=12345&lang=fr
http://www.website.com/text/12345/bonjour_mes_amis.htm
http://fr.website.com/text/12345
(these are not real URLs, i was just showing examples)
Firstly put all code for all languages under one domain - it will help your google-rank.
We have a fully multi-lingual system, with localisations stored in a database but cached with the web application.
Wherever we want a localisation to appear we use:
<%$ Resources: LanguageProvider, Path/To/Localisation %>
Then in our web.config:
<globalization resourceProviderFactoryType="FactoryClassName, AssemblyName"/>
FactoryClassName then implements ResourceProviderFactory to provide the actual dynamic functionality. Localisations are stored in the DB with a string key "Path/To/Localisation"
It is important to cache the localised values - you don't want to have lots of DB lookups on each page, and we cache thousands of localised strings with no performance issues.
Use the user's current browser localisation to choose what language to serve up.
You might want to check GNU Gettext project out - at least something to start with.
Edited to add info about projects:
I've worked on several multilingual projects using Gettext technology in different technologies, including C++/MFC and J2EE/JSP, and it worked all fine. However, you need to write/find your own code to display the localized data of course.
If you are using .Net, I would recommend going with one or more resource files (.resx). There is plenty of documentation on this on MSDN.
As with most general programming questions, it depends on your needs.
For static text, I would use RESX files. For me, as .Net programmer, they are easy to use and the .Net Framework has good support for them.
For any dynamic text, I tend to store such information in the database, especially if the site maintainer is going to be a non-developer. In the past I've used two approaches, adding a language column and creating different entries for the different languages or creating a separate table to store the language specific text.
The table for the first approach might look something like this:
Article Id | Language Id | Language Specific Article Text | Created By | Created Date
This works for situations where you can create different entries for a given article and you don't need to keep any data associated with these different entries in sync (such as an Updated timestamp).
The other approach is to have two separate tables, one for non-language specific text (id, created date, created user, updated date, etc) and another table containing the language specific text. So the tables might look something like this:
First Table: Article Id | Created By | Created Date | Updated By | Updated Date
Second Table: Article Id | Language Id | Language Specific Article Text
For me, the question comes down to updating the non-language dependent data. If you are updating that data then I would lean towards the second approach, otherwise I would go with the first approach as I view that as simpler (can't forget the KISS principle).
If you're just worried about the article content being translated, and do not need a fully integrated option, I have used google translation in the past and it works great on a smaller scale.
Wonderful question.
I solved this problem for the website I made (link in my profile) with a homemade Python 3 script that translates the general template on the fly and inserts a specific content page from a language requested (or guessed by Apache from Accept-Language).
It was fun since I got to learn Python and write my own mini-library for creating content pages. One downside was that our hosting didn't have Python 3, but I made my script generate static HTML (the original one was examining User-agent) and then upload it to server. That works so far and making a new language version of the site is now a breeze :)
The biggest downside of this method is that it is time-consuming to write things from scratch. So if you want, drop me line and I'll help you use my script :)
As for the URL format, I use site.com/content/example.fr since this allows Apache to perform language negotiation in case somebody asks for /content/example and has a browser tell that it likes French language. When you do this Apache also adds .html or whatever as a bonus.
So when a request is for example and I have files
example.fr
example.en
example.vi
Apache will automatically proceed with example.vi for a person with Vietnamese-configured browser or example.en for a person with German-configured browser. Pretty useful.

Resources