I want to write a small extension that is able to take some informations from the database, based on some user filter preference, and show them on the main page.
I have read: PHPBB extensions development and took a look at: ACME DEMO extension but i didn't find an answer to where the database handling should be placed. Normally this should go into a Model that will handle the data to a Controller, in this case I was not able to figure out where the Model should be placed in to the structure and how it should work.
How should an extension database model should be handled? Where should it sit in to the extension structure?
I'm guessing you would need an event listener.
PHP event listeners work with core events to inject code into phpBB.
Core events are like hooks, and they can be found throughout phpBB’s
codebase at key points. They give your extension access to phpBB’s
variables and allow you to use and modify them or to inject additional
PHP code during phpBB’s execution. -per the Skeleton Extension
Page
Related
I am trying to create some dynamic forms using Piranha CMS. As far as I managed to learn it is not supported right now, so I'm looking for work arounds or alternatives.
What I want to do now is use the editor from the manager for other users. To be more precise: this is how the editor looks like inside my manager when I want to edit a page
I have a text input and a select, both are Fields and there are many more fields to be used.
I want the sys admin to create a page with a list of inputs like this, which right now are usable only by the admin. BUT make this list of inputs available for edit to other users as well. Is it possible?
I'm not sure how to extract this editor or behavior or even if it is possible. The problem is we really need the admin to be able to configure different form inputs for users as it is the main core of our functionality.
Any help/advice is highly appreciated, thank you!
The components in the management UI is not designed to be reused in the front-end application in any way. The edit models in the manager contains a lot of extra meta data since the UI is completely generic. If you want to build an edit UI in your front end application, and you're using MVC or Razor Pages, the simplest way is to.
Get the generic model instead of your strongly typed model, for example api.Pages.GetById(...) instead of api.Pages.GetById<T>(...).
Loop the available fields in your selected region (a region is an ExpandObject which can be casted to an IDictionary<string, object>).
Use the built in support in Razor by calling #Html.EditorFor(...) for the fields.
Using this approach you can easily create your own EditorTemplates for the different types of fields you use that will match the rendering in your client application.
Best regards
Håkan
Context:
The Web interface coded in .NET (Grantee Portal for nonprofits applying for grants) is pulling information from the Salesforce Page Layout.
The Salesforce user we use to connect the Web interface with Salesforce via API has 'view all and edit all' rights
Issue:
As it is now, if a field is defined as Read-Only on the Page Layout in Salesforce, it is still editable on the web page (the Salesforce User we use has to have 'view all and edit all' rights)
What we are trying to achieve:
IF a field is defined as Read-Only on the Salesforce Page Layout
THEN the same field should be Read-Only on the Web interface page
Question:
To achieve the above, I guess that I need to fetch the field property for the Page Layout via API. Any ideas on how to do so?
Thank you!
Izumi.
You'll need Metadata API (the set of webservices that let you add new objects, fields, picklist values or even create classes & run unit tests).
Here's the API Guide: http://www.salesforce.com/us/developer/docs/api_meta/index.htm
Depending on how often you modify layouts you might decide "screw it, I'll just use Eclipse IDE". In that case you'd download all page layouts (they're XML files), point your C# app to them and let the magic happen.
Slightly more advanced is to use Migration Tool (Ant / Java based application that can be scripted for periodic download of same stuff).
Super advanced would be to use this API guide to write it in C#. It's not rocket science (here's the specification for Page Layout object and here's the Java sample code for the operation that retrieves the metadata... sorry, no C#). Actually you might be better off looking at this example though: http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_describelayout.htm
Seeing that you'll probably want to cache this info somewhere anyway (I can't imagine your user coming to your page, having to wait for the webservice callout to complete, then having his UI rendered) - pick your poison.
Or share the work within the team (1 person kicks off with files downloaded with Eclipse, other tries to figure out the C# code to retrieve them on demand).
Alright so I learned that to have an upload button on a page, what you do is basically call a php file (call is upload.php) that would upload a file to the server. I have no idea where I am supposed to put the php file inside the server so I can call it.
I feel stupid because I can't find any answers online. I am getting very frustrated and confused because I am told I need to create a database but I have no idea how to edit a database in Joomla. I took a class in SQL so I don't have to learn about that. I just don't know where it is. I was also told I need to make a component. But this is confusing because all I want to do is have an upload button that will upload an image to the server.
I understand your frustration. I've got the basic idea on what you are trying to do. Here are a couple of options:
You might wanna take a look at Joomla! Extensions Directory ™. You might just find there a component or a module that already does this for you.
If you want to do it on your own, than you need to create a small module or a component inside Joomla! Please refer to the Joomla! Documentation or tutorials on this topic. Please note that you won't get this working instantly, because you first need to understand how Joomla! works. So your upload.php file will go in your module / component files. I don't think you need to do any SQL.
Now the part with "allowing a user" is a bit confusing... you want to "allow" any user to upload things to your server or just let's say, registered users? Generally uploading scripts need to be very strong from the security point of view. If this is the case, that you need to do a search for Joomla! ACL
You can simply create a form and add the "media" field type.
http://docs.joomla.org/Standard_form_field_types
You can also opt for the "file" field types to allow different types of fields.
Both fields can be added using the Joomla Component Creator: http://www.notwebdesign.com/joomla-component-creator/
And you might also want to take a look at K2 which has an excellent image upload functionality that allows scaling of images into three different sizes.
I'd like to keep a log of all searches that users do on my site which uses the sunspot-rails gem. I don't need the logs to be real-time accessible by my application as they're for analytics that will be processed later.
I'm thinking that I should do the logging in rails rather than in solr itself so that I have access to the entire session, but I'm not sure how to build that. Is there a standard method for this? I saw this question but I would think there would be something more generic than writing it all myself in ApplicationController.
The ultimate answer depends on howwhere you're implementing your search. If you have a single search controller, do the logging there. If you have a collection of search controllers, either do it in each one, or create a base class, do the filter/logging in the base class.
Can you provide any more details?
I'm a big fan of keeping application logic in the servlet, and keeping the JSP as simple as possible. One of the reasons for this is that any good web designer should be able to expand upon his HTML knowledge to build in a few JSTL tags to do simple iteration, access beans, etc. We also keep the more complex/ajax/js components behind a tag library (similar to displayTag but for our own components).
Most of the time everything works out ok - The servlet does any SQL it needs to, and stores the results in beans for the JSP to access. Where we have a problem is when the records we wish to access are specified by the design.
The clearest example would be the home page - it needs to be eye-catching and effective. It doesn't need to be uniform like rest of the site. There are lots of one-offs or "special cases" here, where we want to query a particular product record, or whatever.
What the designer really wants is a way to get a product bean by the product id so he can access the properties as normal. We obviously don't want to query for all products, and I don't want to query in the presentation.
I'm pretty sure I'm asking the impossible here and that I have to give something up. My question is what?
EDIT
Am I wrong in thinking that all application logic should be complete before calling the JSP? I was under the impression it was considered best practice to do all querying/calculating/processing in the servlet then pass (fairly) dumb beans to a (very) dumb JSP.
There are a couple of methods whereby the actual complexity of the query can be encapsulated in another class (custom tag or bean), and the JSP can call it. This
keeps the JSP simple (goal 1) but the JSP is still "triggering" the query - quite
late in the process.
Have I got this totally wrong and it's fine to do this.
Is it a general rule, but perfectly ok to do this in this instance.
Might I run into problems?
EDIT - Example
I'm hoping this example will help:
The home page isn't a "template" like the category/search pages - it is custom designed to work very well with say a marketing image and a couple of specific product images. It does however have information about those two products which should be obtained dynamically (so the name, and importantly price) stay in sync with the db.
The servlet can't know which products these will be, because if the designer wants to change them/remove them/add more, he should only have to edit the JSP (and possibly XML as one answer suggested).
If I understand correctly, you have logic in the JSP that wants a particular product, but at this point you don't want to query from the DB, and its too late for the servlet to be aware of it.
(A side note, while I respect your will to maintain separation of concerns, the fact that this is an issue clearly shows that your framework has too much logic in the presentation tier...but since we probably can't fix that...moving on).
My recommendation is that your designer creates a configuration XML file that contains whatever special cases it needs for the frontend, and yours servlet can read that, then pass dumb beans back to the JSP.
OR...you break things down into multiple requests using XMLHTTPRequest and call back to the servlet for each individual query, then assemble the page on the client.
It sounds like you need better separation between the display and database code. You should have separate classes that just deal with interacting with the database, and know nothing about display.
Then you just create a method that will look up the product by id and return that bean so the display can pull out the attributes it wants.
You need to create a custom bean which will perform your queries for the front end. Actually, it's probably more like a few beans to get the data for you, according to what you say here.
There's no problem with doing that from a design perspective; it's just that the specific design of the home page has more heterogenous requirements than the rest of your site. Make sure your designer knows that he needs to communicate his needs well to the development team to create the BO for your homepage (or whatever) and thing should go fine.
You are not wrong in thinking that all application logic should be complete before rendering the JSP.
If there is a need to fetch more stuff for displaying in your JSP, it would be another request to the server and another Page cycle. If you are looking for 'interactive' loading experience, you could use AJAX.
In a single page life-cycle, I find it hard to understand why do you have to invoke database calls from a JSP. Hasn't the page been previously posted with all the required form variables to help you find the data in Servlet/Helper classes?
If you could give an example of a case, it would be helpful.
[Edit] Looking at your example, yes your designer (or the admin of the site) should set that information as a configuration, not a part of JSP. Or, you could have a small app/admin page to maintain the information in a database so that it could be changed on the go. When you show your homepage, read the configs and load the appropriate data.
I am not sure what is the question. I f you want to have sql statements out of your jsp pages then you can put them in a property file and just read the property file from the jsp page.