Planning to use php-based CMS to manage content of several sites.
But 2 of them are based on Tomcat + JSP, not php - i can't integrate them directly into CMS, so I need to "inject" them from PHP internal. JSP site implemets several web forms, use ajax and live theirs own life, and I need to wrap it with CMS to manage banners, news, articles and other content, placed around jsp form.
I've wrote an proxy.php that took all requests grabs (with file_get_contents(...)) external sites's HTML, parse it with DOMDocument to add prefix to it's resources (was /js/js.js, became /external_site/js/jw.js and etc.), render html directly with "echo" and configured nginx to get static content based on /external_site/.
But the problem is that external site's forms have buttons and links, and all posts should be handled by servlets.
This is not an ideal solution from all points and all traffic should be passed throught CMS.
Main question is there some frameworks or best practice form making such includings ?
No. It would take a ridiculous amount of time/people to create and support such a framework/system/whatever. Your best bet is to replace jsp engines with the cms you are planning to use.
Жесть какая. Мои соболезнования.
Think there is another idea.
To use cURL like full request/response proxy for JSP requests.
Please, suggest articles or may be a solution of how to create http proxy to plainly pass POST requests (with cookies) without any modifications.
In this way JSP app will expect no difference of who is the source of request. And after getting response, i can prepare correct html for "echo".
Related
Coming from non-JS html interpretation it's kind of hard for me to grasp the concept of loading server-side data to REACT.JS "view".
Let's say I've have a site built on Laravel (using routes). Each route request (e.g. "/", "contact") has it's own view. That view is loaded with data coming from a controller and displayed in the view. If I change the route I'll be redirected to another view and I'll get different data from a different controller.
Now the question. Let's say I have a simple site. Top part is my login information and maybe some notifications icon the content of the page changes with going to different sections of the web.
So If I keep using Laravel routes. Every page will be "re-rendered" + I'll have to manually select which components belong to that part of the site. I'll have to retrieve the information that stays the same from the whole web (e.g. login details + notification) again - this kills the react.js principle doesn't it?
Also, what is the best way to propagate server-site data to React.JS? Should I just "echo" out JSON object to the view and then "use" it in REACT?
Could I be pointed to some meaningful approach of how to use React.js along with PHP.
You mostly answered your question :-) With Laravel, the UI is rendered on the server. React is mostly interesting for client-side UI. That said, not everything can be done on the server, and some user interactions can only be managed by the browser. That is why jQuery became so successful in addition to PHP.
If your app deliver some complex client-side code, it could be usefull to build this code as React components, even if you keep your current server-side router: to make the code easier to maintain, but also to write - once familiar with React way of implementing things.
If you would like to transform your app to fully use React and a client-side router, that enable browsing the app without re-rendering at each page, this is called SPA (single page apps). The react ecosystem is pretty cool for building SPA. Usually, though, the server is just a static server delivering JS files, and the app connects to a REST API of some kind.
In some cases, routes can also be served from the server, for specific purposes:
Faster display of first page
Social Graph tags can be added to the specific page (to enable usable Facebook
or Twitter shares, for example)
Should you need to enable this server-side routing, which makes your app universal or isomorphic, you must use components that can be understood by both the browser and the server, this is why React app are usually served by Node.js, so everything is in Javascript.
Example tutorial about building a universal app with React https://medium.com/front-end-developers/handcrafting-an-isomorphic-redux-application-with-love-40ada4468af4#.h8p6lc23w (your intuition is right in this case, a JSON object with app current data is sent at first render)
Also check the awesome react page (https://github.com/enaqx/awesome-react) if you're interested in the React ecosystem.
Recap:
PHP + React: Easily add complex components to some pages, better to keep it that way if you just have a lot of static content, SEO, and just a few complex components on a single page that React can help you with.
React + API: Common SPA app, better for rich and complex UI, pretty easy to develop if starting from scratch and familiar with javascript, but complexity arise with performance management and SEO on large apps
Universal React: the best of both worlds, setup kinda complex (cf tutorial)
I have previously used reactJS on another project.
When building said project i noticed a downfall namely the loss of SEO benefit associated with JS rendered components.
I am rebuilding an old project and I would like to replace some of the Javascript with ReactJS.
For example, a multi step form - I'd like to replace it with a stateful component that displays the correct stage as required.
I would however like to maintain the SEO aspects of the page by having the first step spiderable.
To achieve this my research implies that I should be using React's React.renderComponentToString
Having researched the issue my thought process is that I should render the components server side using node.js and then serve them up within the browser. The component is then re-added per say to add the client side functionality. My first question is as to whether this is a suitable approach? Is there a much simpler approach that I have overlooked?
Pete Hunt mentions here (https://groups.google.com/forum/#!msg/reactjs/eUespJPdyas/hmJywyo9ZSwJ) that Instagram uses/used Django and had a setup similar to what I imagined.
My app is written in php using phalcon. My question essentially relates to this statement:
Node will then return the HTML that makes up the component. Django
takes that HTML and inserts it into the DOM via normal Django
templates.
How do I go about doing this within PHP? I don't want this component rendered behind the scenes and used when requested, but rather rendered when required by PHP with passed parameters.
I found this question (Sending messages from PHP to Node.js) which got me thinking that one approach is to simply use CURL to query the port my node instance is listening on to get the html which I then output.
My concern here is that all my experiences with CURL have suggested that it is very slow. I don't want my page load times to decrease dramatically just to get some SEO benefit.
Could anyone advise on the above questions/my direction?
Many Thanks
Stoyan Stefanov created a library for calling into the V8 JS library from PHP code for doing this sort of thing; it's available here:
https://github.com/reactjs/react-php-v8js
You can read about how he set up React server rendering in these two posts:
http://www.phpied.com/server-side-react-with-php/
http://www.phpied.com/server-side-react-with-php-part-2/
Rendering won't be instant, but it should be reasonably fast. If you're having performance problems and caching doesn't help, you can consider using Google's AJAX crawling feature in order to use server rendering only for Googlebot but not normal requests:
https://developers.google.com/webmasters/ajax-crawling/docs/getting-started
Note that browsers will also take advantage of server-rendered markup so even if the initial request is slower, rendering may be faster.
I am using PHP mvc framework (Codeigniter) for my web blog.
I am going to implement Ajax for the first time to see the real benefit myself.
I guess what I've done from the view such as formatting and display result on html page can now be replaced by the Ajax implementation. So I guess the view of the the server side mvc would no longer be used.
With a form validation, it is suggested to gear up with logic for both client and server in case javascript gets bypassed. I guess the same concept applies here with Ajax when javascript is disabled from client browser. I mean, you get no data when it's disabled. What would be the back up solution for this scenario like how validation is handled?
You've asked two questions but I'm just going to answer the first one: can AJAX replace the role a server-side view traditionally had?
In MVC web frameworks the view is a template for converting data passed in from the controller into HTML, however, client-side templating languages have become quite popular and are a perfectly reasonable alternative to rendering HTML output on the server, and they have definite advantages.
Firstly, since you're not sending an entire HTML payload to the client browser but instead just the content, you can save significantly on bandwidth. Generating the HTML client side allows you to transmit only data (like JSON or XML) to the client. The server side view would simply contain script tags pointing to the JavaScript templates and the content payload.
Secondly, since these JavaScript templates can be served up from a CDN, you benefit from the speed of those networks plus caching across pages, so the user is likely only downloading those templates which are unique to a specific page as well as data.
However, there are some disadvantages, such as SEO, although there are some workarounds for that. One option would be to serve up an SEO friendly version of the page to crawlers using a server side view, or simply render your templates server-side using Node.js or Rhino. The beauty of writing templates in a language that compiled to JavaScript is that both the server and the browser and execute them, which can be said for no other language.
I've built a fairly complex web app (html, javascript, jQuery, php, mySQL) and use several mechanisms for navigating through the site (e.g. anchor/links, submit buttons, window.location, window.open). I'm looking for two things:
What are all the mechanisms possible for moving around a site or a source that will allow me to find such a list
What, if any, documentation standards are there for documenting such actions; something like the flow charts used to document procedural code.
I'm not sure either by what you mean in "thing 1". The best tool to map all the paths is the UML Sequence Diagram.
Services such as Omniture and Google Analytics let you visualize such paths of user navigation. You could explore that option. Basically they work by tracking a page's URL and its referrer URL (accessible via document.referrer) and then making the connection.
If I understand your comment on dj_segfault properly, I'm not even sure you understand the concept of server/client interaction.
I don't think there is an answer to this because the technology is changing all the time and it is different depending on what devices you are using.
You only have to look at Node.js (if you understand the technology) to see that the lines between server and client can be blurred, and that it's just not a simple answer.
The bottom line is in fact there are no navigation "things" unless you program them, and how you program them is your choice depending on requirement.
For example a vanilla link
Google
Can either be static HTML content or echo'ed from a php script which was used to select the data from a database to get the URL and print it. But it doesn't have to be either of these.
If you wanted to navigate to google you could use a button with an onClick javascript or an event listener with data collected by AJAX. It could be derived from other content values on-the-fly or be a string. I could probably imagine 20 different possibilities but that doesn't make them all suitable for the application.
Just keep incrementally improving your project, use this forum to answer specific questions and you'll learn a lot. I did.
I've been trawling SO for a couple of hours tonight looking for some answers, but I've not found anything that really answers what I'm after. My apologies if it has, in fact, been answered already.
I'm designing a new website and I'm trying to decide on the architecture to use to serve the content. In the past, my websites have used PHP feeding data into Smarty templates.
However, recently at my work, I've been working on a Java web application where jQuery was used to retrieve the data from a RESTful API (which returned JSON), where HTML template pages were used as the base and javascript was used (utilising jQuery) to fill in the content.
My question:
The website I'm designing will be in PHP, but would it be better to construct (or use an existing) RESTful API or to continue on as I've done before feeding the data into Smarty templates?
Are there real benefits to one or the other, or does it just come down to developer preference/experience?
If it helps, the website will be for a church, where the content types will be CMS-like; news/announcements, wiki-like pages, and a limited type of social networking (for the minister to communicate with parishioners).
Short answer: It sounds like filling the content with JavaScript would not be useful in your case. Loading the data with JavaScript is adding a layer of complexity with minimal or no benefit (in your case). Take a look at CMSs and websites that have similar functionality to what you're doing. WordPress, Drupal, etc.
For an example of when it might be useful to load data with JavaScript, check out the tags section on this site. When you search for a tag it queries the server without reloading the page. However, the initial tag list is loaded during the initial page load without any JS.
Here are some cases where you might benefit from loading information with JS:
There is some data that will take longer to load. For example, you're getting data from a web service. Using the traditional method, you would need all the data you need for the page to be available before it can be displayed. If you loaded that data with JavaScript, the page could load and the slow data would appear when it returns. Realistically, you would probably just cache the data but this is just an example.
You will be getting more data as the user stays on the page. You might want to update the page without refreshing.
You want the user to be able to query more data without refreshing the page.
Your users have limited bandwidth (mobile).
This site has more guidelines: http://www.oracle.com/technetwork/articles/javase/index-137171.html