Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/26/20 in all areas

  1. This example is great for demonstrating product images in detail by enlarging the specific area or displaying an enlarged image in a separate area. It does not use two images to produce the effect as many libs do. I have separated the functions in such a way that you can easily choose the one that best suits your project. See External JS file to Magnify and for Zoom function, see Mainform script. I do not see any use of using this feature in mobile as there is already a pinch movement to enlarge images on the platform. Either way, it works the same. Examples posted here are free of charge to uniGUI Subscribers only. Don't ask me to send to you. That's uniGUI forum's rule. Visit http://www.unigui.com.br or http://unigui.express (soon to go live) to purchase our material. Credits: Example from w3schools.com. Telegram Group https://t.me/uniguiExpress Project available at https://unigui.express
    1 point
  2. Responsivity feature like a Bootstrap grid system is a requirement these days, only one web application running in all resolutions with same code would be perfect to uniGUI modernization.
    1 point
  3. in MainModule procedure TUniMainModule.LoadScriptCSS; begin if upMobile in UniMainModule.UniPlatforms then begin UniSession.AddJS('Ext.Loader.loadScript("/files/' + cCSSDir + 'custommob.css")'); end; if upDesktop in UniMainModule.UniPlatforms then begin UniSession.AddJS('Ext.Loader.loadScript("/files/' + cCSSDir + 'custom.css")'); end; end; procedure TUniMainModule.UniGUIMainModuleBeforeLogin(Sender: TObject; var Handled: Boolean); begin LoadScriptCSS; ... ... end;
    1 point
  4. Responsive Layout very important to a web application
    1 point
  5. HyperServer should grow to HyperServer Farm with Load Balancing. Current HyperServer is enough for many applications, but if the application must serve many clients, one node will not be enough As soon as there are several HyperServers, server affinity, load balancing, keeping truly global sessions will become issues. It is something like what happens with RemObjects DataAbstract and RemObjects SDK Olympia. A Run-Time Designer will solve many of the issues raised by many people. It could allow modifying an existing design or creating a visual design from scratch. As this component will execute at run-time, it will allow seeing what the customer will see. This fact will solve all the issues related to setting the correct properties for achieving the perfect alignments and any other visual properties. It should be possible to save the design (*.FRM) for loading it at run-time or use it for adding it to the original project. In this case, it will be possible to define Delphi events for server-side event handling. If desired, despite loading the design at run-time, it could be possible to capture client or server-side events (in Delphi or using some scripting language). Server Module shared repository Some application tasks or memory structures are global and shared between sessions. While in current UniGUI it is the developer responsibility to create and administer the access to these structures, when having multiple instances of an application, under a HyperServer or in a Server Farm with multiple HyperServers, UniGUI should provide some additional support to make it easier and standard. This kind of global repository should provide a messaging infrastructure with point-point, broadcasting, publisher/subscriber, etc. making it easy to create real-time (chat) applications, offline messaging, etc. Marketplace Free or paid components I have a dream (I'm not Malcom X) about components like those used in electrical designs. I'll add more details later... A few examples of possible generic solutions packed as database schemas and components: Role-Based Access Control (RBAC) Explicit class-to-entity mapping in the database (supporting inheritance, logging, versioning, deep copy for complex objects, dynamic classes, generic annotations) Workflow Designer and Workflow Engine (with roles, work lists, statistics, chains of approval) Responsive Design I didn't add this feature explicitly because it should be part of the Designer (mentioned as the second feature). The Designer could be used at design-time or run-time. Whatever is created could be saved as a .DFM to replace the previous design or to override it at run-time. If no scripting is needed, or if the code is already available as actions in a data module, it should be possible to keep the design only run-time. If there is no way to code something required for the form, the design should be further developed at design-time. In any case, the responsive features should be defined in the design, Delphi-style, with more options than just the client-side JavaScript code.
    1 point
×
×
  • Create New...