This is more a theoretical question than a coding question. I am trying to create a epub, with some interactive components. Now to separate the code, I put each interactive component in a separate html file. Typical interactive components will be a questionnaire.
What will be the best way to link this to my epub, two options I am considering are:
Iframe - the interactive component will display as a part of the book, and users will seamlessly complete the activity.
External link - an Icon will be displayed in the book, which will serve as a link to a new page, this page will contain the interactive component.
I would like to keep the epub according to epub 3.0 standard.
Any suggestions or alternative solutions I can research?
Either approach is compatible with the standard since external links are allowed and scripting within an iFrame is also allowed (known as scripting in a container).
The broader question is what are you trying to achieve? If the user is sent to an external page in a browser then the browser will have to post the results back to some server since the browser can't write the results back to disk or the EPUB.
It also depends on whether the EPUB Reading System is browser-based itself or an app. It is an app then in theory the app might know how to log info locally (though that would require jumping through some hoops that could have security implications.
So what is the goal here?
Related
Does anyone know if I can integrate GrapeJS into my own website so clients could build their own websites using it? IF anyone has done this, how easy is it and are there downsides?
This question is pretty open ended, but I'll take a shot at it.
The short answer is yes, you can use Grapesjs to allow clients to make their own sites; however, the details matter.
Grapesjs by default doesn't know anything about your stack, website structure, metadata, etc. You will need to either supply plugins or implement those features yourself. I've worked on a project for a company that used Grapesjs to implement single page apps and I'll include just some of the tweaks we had to manage.
Hiding certain layers that only confuse average users.
Hiding pretty much all of the styling, and using traits to allow people to pick from some predefined styles.
Take the html, css on store and generate the final html page, and store it in our static serving folder on the server.
Implement a wrapping "App" component that has traits for the different metadata we want users to control (open graph metadata, title, etc)
and those are just the big things, I'm sure I am forgetting several small ones.
For your application, you'll also need to implement a custom trait for links / buttons that allows you to link from one "page" to another. As well as, a way to allow a user to pick which page to work on.
The long answer is Yes, but Grapesjs is only the starting point.
Yes you can.
However it is not straightforward.
If you want to build a Drag Drop Editor like GrapeJS Demo, here is the Source Code - https://github.com/artf/grapesjs-preset-webpage
You can see an implementation at https://codegres.org/dragdrop
First, a short disclaimer. I have next to no knowledge about web applications. I come from an iOS background where I exclusively wrote native code, so if you write your answers like I know nothing outside the shallow parts, that would be great.
I'm interested in learning a stack to develop web applications, but I'm not sure what the right way to build the GUI is. I know that a web front end consists of html and CSS to create the display and javascript as the bridge between the back end and the GUI, but I don't know the best way to put something together.
I know in iOS, you can use the Interface Builder (part of xcode that lets you graphically create the xml that describes the display) to create GUI's without any knowledge of how iOS translates the xml to some rendering, or even what is written in your xml files. Is there any analog to the web front end?
I'm mainly just looking for a list of the accepted ways to develop the GUI for a web application. If I have to learn HTML and CSS, so be it, but I'd like to know what my options are and the tradeoffs between each of them.
I can answer shortly stating that (technically) you can design web pages without coding in HTML or CSS, or even Javascript - although, you would be somewhat limited in your creative abilities and applications.
You can read about WYSIWYG html editors on this link, or try out ckeditor (someone said it's good)...
...I think a bit of background will help you reach a correct decision...
so here goes:
The Long Answer
I would start by trying to put the world of web programming and design into concepts that correlate with iOS coding.
If we look at the whole of a web app from an MVC perspective, then the browser is the view, the server is the controller and the database is the model... although this is very simplified.
Just like in iOS, each of these can be (but doesn't have to be) broken down into sub-MVC systems.
Just like any model in MVC, the view (the browser) can talk to the model (the database), but really it shouldn't. that's just bad practice.
If we break down the main-view (the browser) to a sub-MVC system, I would consider the HTML as the model, the CSS as the view and the browser (through links and javascript) as the controller.
It's not all that clear cut, but thinking like this helps me practice better and cleaner coding.
The HTML is the view's model for the web-app - it contains the data to be displayed or used.
HTML is a variation on the XML format and it contains data organized in a similar way to an XML file.
The basic HTML file will contain:
<html>
<head>
</head>
<body>
</body>
</html>
this should look familiar to you if you read any XML.
The CSS (cascading style sheets) is the view - it states HOW the html DATA should be displayed.
if your web app does't have any CSS, it will use the browser's default CSS/styling to be applied on the data in the HTML.
This "language" makes me think more about dictionaries in iOS (I think that's what they're called in Objective C). They have properties and values (like key-value pairs) that determine how the HTML data is displayed (if it's displayed).
They could look something like this:
body
{
color: white;
background-color: black
}
The browser is the web-app's view's controller - it makes it all work together and serves it up to the screen.
Javascript and links help us tell the controller what we want it to do, but it is the browser that acts (and willfully at times).
You can have a whole web app that acts without javascript, using only the default actions offered by links - in which case the browser will usually ask the server (the main controller) what to do.
Javascript helps us move some of the legwork from the server to the client, by allowing us to have a "smarter" controller for our view - just like in iOS.
The issue of the errant main-view / browser
Not all views are created equal, and not all browsers are the same.
Because the browser is used as the controller for the web-app's view, and because some browsers act differently then others, we web coders have the problem of working around someone else's idea of how our view's controller should behave.
You might see us complaining about it quite a lot (especially complaining about Internet Explorer).
These days, this issue is not as big of a problem as it used to be... it's just that some people don't update their computers...
WYSIWYG web editors
There are website builders and editors that try to work like X-Code does, by allowing us to build the website much like we would write word documents.
But, unlike X-Code which codes only the graphical interface of the view, these website builders write the model as well and usually add javascript into the mix.
When we use these tools (which I avoid), the whole MVC model breaks apart.
We can use them as a starting point for dirty work, but then we take their code apart and adjust it to our needs - usually by taking the code we need for the view (CSS) and applying it where we need it (and discarding much of the nonsense they add to the code and the HTML).
To summarize
As you can tell, HTML and CSS (and Javascript) are only a small part of a web app - as they all relate to the main view of the web app.
To write the controller and models for web apps, we use other tools (such as Ruby, PHP, js.node, MySQL and the like).
Coding the HTML and CSS isn't as hard as you might think, although it might be harder then I present it to be.
You can avoid writing code for web apps and use applications that offer WYSIWYG (What You See Is What You Get), but that would limit your abilities and will take away from your control over what you want to create.
I'm creating a web site for an institute, since I'm new to this field I want to know whether I can create a page for header part(which containing the logo and the name of the institute) and can I combine that page to each and every page I'm creating. If it is possible suggest me how can I combine the header part & newly created page..
Surprisingly, there is no way to do that in straight HTML. Not even in HTML5.
If you are only creating a few pages, I suggest simply copy-pasting the content to each page's HTML file. Admittedly, that approach can quickly become a burden.
Some web servers will parse the HTML of a page before it is served out, look for a specific kind of HTML comment, and then interpret that as a command to insert the contents of another file. This feature is called "server-side includes" or "SSI". Some web servers, such as Apache Tomcat, have this feature but turn it off by default due to security concerns.
If you are building dynamic pages where the HTML content being served is created on-the-fly with a programming language rather than read from pre-created disk files, then you can definitely include fragments of HTML using that programming language.
I suggest you do some additional study to build up your web authoring skills. One great source of training is the book "Head First HTML with CSS & XHTML" from O'Reilly Media, Inc.
You can do pull html code from different places and merge them with php. It's been years since I've done it, so I can't get into the particulars.
I am planning to create a small research web application, that will have a graphical data representation control as a main data layout mechanism. The following sketch shows a primitive layout for a part of a web page:
Since it will be a part of a web app displayed in browser, I want to have some logic that allows me to create, edit and render such "maps" or you can call it "hierarchical trees" into HTML markup to sent to the browser.
Maybe one of you knows a good and elegant way to create such visual elements in plain html.
If not - I am a .Net developer, so I can, as a last resort, reduce to using a silverlight to render such visuals, but than I will have a huge visitor loss on a first visit, since most of them, I suppose, won't be willing to install Silverlight Plugin, just to get acquainted with my web site.
Anyways, a plain HTML generator for such visual trees, or a Silverlight analog will be great. Thanks for the tip in advance.
P.S. I need the element to be interactive, so generating a simple image on a server is not the solution.
The JavaScript vector engine Raphael is a great option.
But if you just want to render the map and display the result on your page, then I recommend GraphViz which takes in a description of your graph in a simple language and outputs the graph in a few different formats.
HTML has had frames from early days, but they are deprecated in the latest version. Many browsers (I have tried with Internet Explorer) don't even display frames properly.
Why has this been done? What was the drawback in frames?
Jakob Nielsen wrote a 1996 column that criticized frames. Some key points:
Frames prevent users from properly bookmarking pages. When a bookmarked frameset page is loaded, users' previous mouse clicks inside the frames do not matter. Only the outer URL is saved, and users have to navigate to where they were manually.
Frames present challenges for printing web pages. Printing all the frames at once is not suited to the different dimensions of paper (and users can get only the first pageful that way). Users generally have to right-click the frame they want and choose the appropriate context menu option.
Users coming from search engines may not have access to navigational elements if they are located in another frame — they are directed to only that frame the search engine found the text in.
While "framesets" (the most common type used on late 1990s/early 2000s web pages) are dying, the iframe (short for inline frame) remains alive and well. In fact, recently iframes have been found useful in today's "mashup" web applications, and extensions to the iframe are currently proposed in the HTML5 specification.
For example, Facebook, in its API for app developers, uses them to seamlessly integrate third-party apps with their own site while minimizing the security risk. (In this model, all third-party code remains on a separate domain, which is good for security reasons.)
Frames are not deprecated in HTML. They are obsolete in HTML 5, and just discouraged before this version. This has been clearly mentioned in the specified links.
Not to answer the OP but rather balance the bashing of framesets.
I find them great and nothing comes close to them when you want your menu intact and still:
Visually incorporate 3-rd party pages/apps (phpmyadmin or similar)
Viewing doctypes other than html (pdf's or images).
Due to its width="x,*" you get a simple "responsive" behaviour.
Also, you can provide smooth menu-animations while fetching main contents.
Used with sense, they're super.